Implementazione di una piattaforma SSO tra diverse lingue e piattaforme server

Question

Implementazione di una piattaforma SSO tra diverse lingue e piattaforme server

#1 da (3 voti)

-2

La nostra azienda utilizza una piattaforma di terze parti per gestire una porzione piuttosto ampia della nostra attività, ma la piattaforma è basata su JSP e MySQL. Tuttavia, i nostri prodotti sono scritti in C # /. Net. Attualmente stiamo ricercando metodi per essere in grado di implementare un SSO tra questi due servizi senza troppi sovraccarichi. L'SSO sarebbe praticamente a senso unico, dal progetto JSP fino alla nostra app web C #.

Ho letto su SSO e sembra che ci siano molte informazioni diverse là fuori su ciò che è la pratica migliore.

In produzione, vogliamo solo essere in grado di accedere al progetto JSP e fare clic su un collegamento che ci registrerà nella nostra applicazione C #, ma non sto trovando molte informazioni sull'argomento.

c# jsp sso

posta JD Davis 06.02.2017 - 20:35

fonte

1 risposta

Leggi altre domande sui tag c# jsp sso

Qual è un modo efficace per implementare "Stack" senza generici? Opposto di mutare [chiuso]

score 3 · Answer 1

Esistono due modi generali per eseguire un SSO:

Point-to-point

L'App A e l'App B condividono una chiave segreta prima del tempo.
L'utente accede all'App A utilizzando la pagina di accesso esistente.
L'app A deve trasferire il controllo all'App B,.
L'app A genera un ticket SSO temporaneo e lo crittografa utilizzando il segreto.
Il ticket contiene l'ID utente, un timestamp, i metadati personalizzati e il padding casuale (per contrastare attacco in testo normale noto ).
L'App A emette un reindirizzamento ad AppB, passando il ticket.
L'app B legge il ticket, lo decrittografa ed esegue la propria forma di autenticazione utilizzando il ticket anziché qualsiasi tipo di password.
Il biglietto scade entro un breve periodo (meno di un minuto).

Enterprise

Costruisci un terzo sistema noto come provider di identità . O ne usi uno esistente, come Google+ o Facebook, se questo si adatta al caso aziendale.
Rimuovi il codice di autenticazione dall'app A e dall'app B e lo sostituisci con un'integrazione con il provider di identità.
Quando un utente deve accedere ad entrambe le app, il sistema reindirizza l'utente a una pagina di autenticazione centrale (pagina SSO) in cui l'utente accede, controllando l'identità con il provider di identità e avviando una nuova sessione. Può quindi navigare verso l'App A o l'App B senza dover inserire nuovamente le sue credenziali.
Entrambi i servizi di chiamata App A e App B sul provider di identità per confermare che l'utente è chi dice di essere e che è in corso una sessione valida.
Né l'App A né l'App B hanno una propria pagina di accesso.
Due sistemi popolari che supportano l'SSO aziendale sono OATH e SAML .
Questo tipo di installazione potrebbe richiedere un meccanismo keep-alive per aggiornare la finestra scorrevole della sessione.
Questo non è banale, ma una volta installato, sarà scalabile per includere tutti i sistemi introdotti successivamente.

Hybrids

Puoi anche combinare quanto sopra, ad es. invece di un ticket crittografato e un segreto condiviso potresti esporre un servizio di provider di identità su una delle app e l'altra app si integrerebbe con essa. Se ti viene in mente un sistema di autenticazione ibrido, ti suggerisco di pubblicarlo su InfoSec per ottenere la revisione del design.