IAM & SSO

Chi sei, e chi lo garantisce

Ogni sistema che gestisce utenti risponde, prima o poi, a due domande diverse che quasi tutti confondono: chi sei e cosa puoi fare. La prima è autenticazione e appartiene all'identity provider. La seconda è autorizzazione e quasi sempre appartiene all'applicazione, che conosce il proprio dominio di business meglio di qualunque IdP. Confonderle è la radice della maggior parte dei buchi che trovo negli impianti SSO delle PMI.

In questa categoria raccolgo il lavoro concreto su identità federata e single sign-on: protocolli come OIDC, OAuth2, SAML e LDAP, identity provider self-hosted, integrazione fra applicazioni scritte in linguaggi e framework diversi, e la parte che nessuno racconta mai, cioè cosa succede quando l'IdP va installato, aggiornato e tenuto in alta disponibilità su hardware che paghi tu.

Il taglio è ingegneristico e verificato sul campo: codice reale ripulito dai riferimenti al cliente, configurazioni che girano in produzione, decisioni di design motivate e compromessi dichiarati. Non teoria dei protocolli, ma il punto in cui i protocolli incontrano un gestionale che esiste da dieci anni e non può essere riscritto.

Un token è un'istantanea, un permesso è uno stato: se il secondo viaggia dentro il primo, la revoca smette di funzionare. È il principio che attraversa tutti gli articoli di questa categoria.

Se stai valutando di centralizzare le identità della tua azienda o di federare due applicazioni che oggi hanno login separati, nel mio profilo professionale trovi l'esperienza concreta su integrazioni IAM end-to-end, dall'installazione dell'IdP fino all'autorizzazione applicativa.