SAML per un cliente enterprise in un pomeriggio
Un cliente aziendale vuole l'accesso tramite Entra ID o Okta. Cosa serve con EAuth, cosa fa il suo reparto IT e cosa manca ancora.
Il primo cliente aziendale che dice «la nostra gente accede tramite Entra ID» è di solito il momento in cui un piccolo prodotto scopre quanto costa costruire software enterprise. SAML è vecchio, prolisso e pieno di modi per sbagliare, e il reparto IT del cliente lo testerà con un solo provider, il suo. Con EAuth tutto si riduce a una pagina nella console. Questo articolo la percorre, comprese le parti che non sta a noi accelerare.
Prima le organizzazioni
In EAuth il single sign-on appartiene a un'organizzazione, non alla Sua applicazione nel suo insieme. Un'organizzazione è un cliente: un gruppo di account della Sua applicazione, ciascuno con un ruolo, un dominio e-mail che il cliente ha verificato e, se lo desidera, un collegamento al suo provider di identità.
Quindi due cose vengono prima di SAML. Spunti Enable organisations nelle impostazioni dell'applicazione, poi crei l'organizzazione del cliente e verifichi il suo dominio con il record TXT che mostra la console. Il dominio decide chi viene mandato al provider, e impedisce che il provider di un cliente si faccia garante degli indirizzi di un altro cliente. Senza un dominio verificato, il single sign-on non si può attivare.
Cosa fa Lei
Apra l'organizzazione, scelga Set up single sign-on, e la console mostra la parte di EAuth del collegamento: un entity ID, un reply URL e dei metadati da scaricare che contengono entrambi, insieme al certificato di questo collegamento. Ogni collegamento ha la propria coppia di chiavi RSA a 3072 bit, quindi la configurazione di un cliente non tocca mai quella di un altro.
L'amministratore del cliente crea presso il proprio provider un'applicazione con questi due valori, oppure importa i metadati, e Le rimanda i suoi metadati di federazione. Li incolli nella console, oppure inserisca a mano l'entity ID, l'URL di accesso e il certificato di firma. Decida due cose: se le persone diventano membri al primo accesso, e se i membri possono accedere all'organizzazione solo tramite il provider. Poi attivi il collegamento.
La Sua parte è tutta qui. Preveda un pomeriggio, e metta in conto che la maggior parte del tempo se ne andrà nello scambio di e-mail a metà strada e nella ricerca, da parte dell'amministratore del cliente, delle giuste impostazioni degli attributi.
Il provider deve accettare le richieste di accesso tramite redirect HTTP, come fanno Entra ID, Okta e Google Workspace, e inviare l'indirizzo come NameID o come attributo e-mail. I nomi di attributo predefiniti sono quelli che inviano Entra ID e Okta; dove un provider è diverso, i nomi si impostano nella console. Un provider che fa solo accessi IdP-initiated, in cui invia una risposta che nessuno ha chiesto, non è supportato, ed è una scelta. La sezione sui controlli spiega perché.
Cosa vedono le persone del cliente
Quando la Sua applicazione indica l'organizzazione nella richiesta di autorizzazione, con il parametro organization e il suo id o slug, una persona che non ha effettuato l'accesso va dritta al suo provider senza digitare nulla. È così che funziona un pulsante «Accedi con SSO» nel Suo prodotto.
Quando non lo fa, la pagina di accesso di EAuth ha un pulsante Use single sign-on: la persona digita il suo indirizzo di lavoro e viene mandata al provider della sua organizzazione. Inviare il modulo con un indirizzo del dominio e senza password ha lo stesso effetto. Anche la registrazione con un indirizzo del genere passa dal provider, perché è il provider a creare l'account.
Il primo accesso tramite il provider crea l'account presso la Sua applicazione, già confermato e senza password. Questo conta dal 3 ottobre, da quando EAuth non consegna più a nessuna applicazione un account il cui indirizzo nessuno ha confermato: per questi account, la parola del provider è la conferma. Con l'adesione al primo accesso attivata, l'account entra anche nell'organizzazione con il ruolo predefinito. Con l'opzione disattivata, non entra in nulla finché qualcuno non lo invita, e la Sua applicazione riceve access_denied per l'organizzazione.
Un account che esisteva già con quell'indirizzo mantiene il suo id e le sue appartenenze. Se il proprietario aveva confermato l'indirizzo, viene collegato così com'è. Se nessuno l'aveva fatto, potrebbe averlo registrato qualcun altro, quindi, sulla parola del provider, passa alla persona garantita: password, passkey e secondo fattore spariscono, le sessioni terminano e il Suo webhook riceve session.revoked con il motivo.
Con solo tramite il provider attivato, password e passkey smettono di contare per l'organizzazione. Una password digitata per un indirizzo del dominio non viene nemmeno guardata, i refresh token dell'organizzazione terminano quando l'impostazione entra in vigore, e un token nato da un altro tipo di accesso viene rifiutato quando viene usato.
Cosa controlliamo su ogni risposta
Questa è la parte che richiede tempo per essere costruita, e il motivo per prenderla da chi l'ha già fatto. La verifica delle firme XML è compito di una libreria mantenuta: gli attacchi di signature wrapping hanno violato implementazioni di grandi vendor, perché la canonicalizzazione XML ha sottigliezze che superano ogni test scritto da uno sviluppatore. La libreria verifica la firma con il certificato che Lei ha incollato, mai con uno arrivato dentro la risposta, e controlla destinazione, emittente, orari e destinatario.
Oltre a questo, EAuth lega ogni richiesta al browser che l'ha avviata, con un cookie che solo quel browser possiede, quindi una risposta ottenuta altrove e inviata da un altro browser non fa accedere nessuno. Una richiesta resta aperta per dieci minuti e riceve una sola risposta, e ogni id di asserzione viene ricordato più a lungo del periodo in cui l'asserzione potrebbe essere accettata, quindi una risposta intercettata e inviata una seconda volta viene rifiutata. L'audience deve essere l'entity ID di questo collegamento, e l'indirizzo asserito deve stare nel dominio verificato dell'organizzazione.
Quando una risposta viene rifiutata, la persona lo vede, e la pagina dell'organizzazione nella console mostra il perché: una firma che non corrisponde, un'audience o un reply URL sbagliati presso il provider, un indirizzo fuori dal dominio, un provider che non ha autenticato di nuovo la persona quando gli è stato chiesto. È lì che bisogna guardare mentre l'IT del cliente configura il collegamento, e così si risparmia il giro in cui ognuna delle due parti scrive all'altra «non funziona».
Rimuovere persone, e accessi freschi
Quando il cliente rimuove qualcuno presso il suo provider, quella persona non può più accedere tramite il provider. EAuth però non viene a sapere della rimozione. I refresh token che la Sua applicazione ha già per quella persona continuano a funzionare fino alla scadenza, cioè fino a 30 giorni, a meno che il membro non venga rimosso o sospeso nella console o che l'organizzazione non venga sospesa. In questi casi i refresh token dell'organizzazione terminano subito, e gli access token già emessi scadono entro 15 minuti.
Un'applicazione che vuole un accesso fresco può chiederlo. Con prompt=login si chiede al provider di autenticare di nuovo la persona (ForceAuthn), e una risposta che riporta un accesso precedente viene rifiutata. Con max_age, la sessione del provider stesso vale se è abbastanza recente, e se non lo è il provider viene interpellato di nuovo. L'auth_time dell'ID token è il momento in cui, secondo il provider, la persona si è autenticata, e la sessione di EAuth termina non più tardi di quanto indica il provider.
Cosa non fa
Non c'è provisioning SCIM: gli account compaiono al primo accesso, non vengono creati prima né rimossi dopo che il provider ha escluso qualcuno. È il vuoto della sezione precedente, e il motivo per cui conta il pulsante di rimozione nella console. I claim dei gruppi del provider non vengono mappati sui ruoli; i ruoli nell'organizzazione si impostano nella console. L'artifact binding non è supportato.
Una parola sui test. I nostri test end-to-end girano contro un provider di identità costruito sulla stessa libreria SAML, che firma le risposte come fanno Entra ID e Okta. Questo mette alla prova il protocollo e i nostri rifiuti. Non equivale a una sessione nella console di amministrazione di ciascun vendor, e il primo collegamento con un dato provider è il momento in cui emergono le sue impostazioni particolari. Il motivo del rifiuto sulla pagina dell'organizzazione serve proprio per quel pomeriggio.
Fonti
- Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS, consultato il
- SAML Security Cheat Sheet, OWASP, consultato il
- On Breaking SAML: Be Whoever You Want to Be, USENIX Security 2012, consultato il
- Single sign-on SAML protocol, Microsoft, consultato il
- Enterprise SSO with SAML, EAuth documentation, Elchi Studios, consultato il
Scritto da Samuel Krauss, Founder. Archiviato in eauth, saml, sso, organisations.
Tradotto dall’inglese. Leggi l’originale inglese