Pro e contro di avere due provider di identità

Naviga le tue risposte
4

La mia azienda ha applicazioni su cloud e intranet. Inoltre, abbiamo diversi ruoli come dipendenti, clienti, partner ecc. Vorremo la federazione ID tra servizi ospitati su cloud pubblico e applicazioni interne. Gli scenari seguenti sono possibili

  1. Dipendente che accede ai servizi cloud dalla intranet
  2. Dipendente, clienti, partner che accedono ai servizi cloud da internet
  3. Servizi ospitati nel cloud che accedono ai servizi di dati ospitati internamente sulla rete aziendale
  4. Dipendente, clienti, partner che accedono alle applicazioni / servizi web ospitati internamente su rete aziendale da Internet.
  5. Dipendente, clienti, partner che accedono a applicazioni / servizi Web ospitati internamente su reti aziendali da intranet.

Ogni volta che l'accesso è da Internet a applicazioni internamente ospitate o applicazioni basate su cloud, SSO deve essere creato tramite autenticazione a più fattori, ma se si accede alle stesse applicazioni da intranet, la password userid è sufficiente o se l'utente è un dipendente, la società SSO deve essere federata a servizi / applicazioni basati su cloud.

Stiamo discutendo se ci sono pro o contro di avere due provider di identità, uno distribuito in DMZ e altri nella rete interna. Quello in DMZ imporrà l'accesso passando da servizi intranet a servizi basati su cloud o gli utenti che accedono a servizi basati su cloud da Internet verranno federati a questo IDP. Inoltre, gli utenti di Internet che cercano di accedere alle applicazioni interne otterranno il multi fattore autenticato da questo IDP in dmz. L'IDP all'interno della rete interna viene utilizzato solo per i dipendenti che accedono alle applicazioni intranet.

La mia domanda è che il tipo IDP sopra descritto sia un modo standard per consentire l'accesso? Qual è il danno di avere un solo IDP?

    
posta Jimm 17.08.2013 - 19:52
fonte

1 risposta

1

Il modo più semplice per me è identificare un singolo fornitore di identità (autenticazione / autorizzazione) come "Fonte autorevole". Questo memorizzerà tutte le tue informazioni di identità su tutte le tue applicazioni e servizi.

Ciò fornirà il record principale con cui sarà possibile fornire l'autenticazione e l'autorizzazione per tutti gli utenti. Questa singola fonte autorevole dovrebbe quindi essere in grado di alimentare i dati nella zona DMZ per fornire le informazioni alle altre applicazioni disponibili sul cloud. Ciò garantisce che gli account non possano essere rianimati a causa di qualcuno che abilita un account all'interno della DMZ.

Questo aiuta molto quando si eseguono il provisioning e le identità di deprovisioning in quanto sarà necessario rimuovere l'utente da un record piuttosto che disattivarlo su due o tre fonti diverse. (Crea processi disperati e causa debolezze nel tuo processo IdM.) 

|   Cloud Infrastructure  |
---------------------------
|          Internet    ^  |
|                      |  |
---------------------------
|    DMZ               |  | <= External copy of authoritative source (read only from external)
|                      |  |
--------------------------|
| Internal - Authoritative| <= Authoritative Source (HR records/etc) reside here.
    
risposta data 17.07.2014 - 21:26
fonte

Leggi altre domande sui tag

Suggerimenti per fax sicuro SaaS [chiuso] Che cos'è cleardot.gif accanto alla firma dei mittenti in Gmail? [chiuso]