Single Sign On per un'app Web

Question

Ho cercato di capire come questo problema viene risolto per oltre un mese. Ho davvero bisogno di un approccio generale che funzioni. Ho una teoria, ma non sono sicuro che sia l'approccio più semplice (o corretto) e non sono stato in grado di trovare alcuna informazione a supporto delle mie idee.

Ecco lo scenario:

1) Si dispone di un applicazione web complesso che offre contenuti sicuri su abbonamento.

2) Gli utenti devono accedere alla propria applicazione con nome utente e password.

3) Si vendono a grandi società, che dispongono già di una tecnologia di autenticazione aziendale (ad esempio, Active Directory).

4) Si desidera integrare il meccanismo di autenticazione aziendale per consentire ai propri utenti di accedere alla propria app Web senza dover immettere nome utente e password.

Ora, qualsiasi soluzione si arriva con dovranno fornire un meccanismo per:

• aggiunta di nuovi utenti
• rimozione di utenti
• modifica delle informazioni utente
• consentendo agli utenti di log-in

Idealmente, tutto ciò sarebbe accaduto "automaticamente" quando il cliente aziendale ha apportato le modifiche corrispondenti a la propria autenticazione

Ora, ho una teoria che il modo per farlo (almeno per Active Directory) sarebbe per me scrivere un'app lato client che si integri con Active Directory del cliente per tracciare le modifiche mirate e quindi comunicare quelle modifiche alla mia app Web. Penso che se questa comunicazione fosse effettuata tramite i servizi Web offerti dalla mia app Web, allora manterrebbe un livello di sicurezza inammissibile, che ovviamente sarebbe un requisito per questi clienti aziendali.

Ho trovato alcune informazioni su un prodotto Microsoft chiamato Active Directory Federation Service (ADFS) che potrebbe essere o meno l'approccio giusto per me. Sembra un po 'ingombrante e ha alcuni requisiti che potrebbero non funzionare per tutti i clienti.

Per altri scenari ID esistenti (come Atene e Shibboleth), non penso che sia necessaria un'applicazione client. Probabilmente si tratta solo di collegare i servizi ID esistenti.

Gradirei qualsiasi consiglio su chiunque abbia menzionato qui. In particolare, se puoi dirmi se la mia teoria è corretta sulla fornitura di un'app lato client che comunica con i servizi Web lato server o se sto andando nella direzione sbagliata. Inoltre, se potessi indicarmi qualsiasi sito web o articolo che spiega come farlo, lo apprezzerei molto. La mia ricerca non è stata presentata molto finora.

Infine, se potessi farmi sapere di eventuali applicazioni Web che attualmente offrono questo servizio (in particolare come legato ad un Active Directory aziendale), sarei molto grato. Mi chiedo se altre app Web B2B come salesforce.com o hoovers.com offrano un servizio simile per i loro clienti aziendali.

Odio stare al buio e apprezzerei molto la luce che puoi versare ...

Jeremy

Answer 1

Shibboleth è progettato per supportare esattamente questo scenario. Tuttavia si affiderà alle aziende dei tuoi clienti che implementano i meccanismi del provider di identità. Al momento, questo è molto comune nelle università. Inoltre, se si desidera che le informazioni dell'utente (più di un semplice identificatore pseudonimo), è necessario che la società accetti di rilasciare tali attributi all'utente.

Trovo difficile credere che molte aziende aprano il proprio sistema di autenticazione aziendale, solo per fornire SSO.

Potrebbe essere meglio fare affidamento su OpenID o simile e utilizzare un cookie "ricordami" per ridurre la necessità per le persone di immettere password.

Answer 2

Un problema di base con il tuo approccio è che stai considerando la tua app web da sola. I dipendenti dell'azienda del tuo cliente non solo richiedono SSO per la tua app Web, ma anche alcuni/pochi/molti altri, e l'estensione del tuo approccio richiederebbe un'implementazione su misura per ciascuno di questi per consentire l'accesso.

Da qui l'adozione diffusa di OpenAthens e Shibboleth nella comunità delle biblioteche accademiche per sfruttare l'uso di credenziali emesse localmente. Una tipica università di medie/grandi dimensioni può sottoscrivere vari prodotti/servizi da più di cinquanta diversi editori e, implementando OpenAthens/Shibboleth, può sfruttare lo standard aperto SAML (SAML è il protocollo utilizzato da Shibboleth) che sta assistendo a una maggiore presa di non solo nel settore accademico, ma anche nel settore commerciale.

La risposta di John sopra fa riferimento a un altro problema: ci sono una serie di standard aperti recentemente emersi, SAML e OpenID tra questi. Quindi i fornitori di contenuti devono decidere se vogliono implementare alcuni o tutti questi in modo nativo, ma usano stack tecnologici separati e quindi i costi di implementazione e supporto possono essere duplicati.

Alcuni importanti editori hanno implementato OpenAthens in quanto supporta Atene, SAML/Shibboleth e OpenID in un'unica piattaforma, con opzioni per collegare anche altre tecnologie, o scrivere un modulo personalizzato per consentire a un'app interna di connettersi, ad es. una fatturazione o di sistema di diritti di registrazione che gli utenti dei clienti accedono a.

Questo settore della gestione degli accessi è decisamente muovendo verso standard aperti, in modo da costruire il proprio metodo sarebbe privare l'accesso alla vostra applicazione per un gran numero di utenti