4.6.2 Federation & SSO

Federation and Single Sign-On (SSO) let a user authenticate once and then reach many separate systems without re-entering credentials.

Directory Services and LDAP Centralized identity usually starts with a directory that stores users and attributes. - LDAP (Lightweight Directory Access Protocol): an open protocol for querying and modifying directory services such as Active Directory, over port 389. - LDAPS (LDAP over SSL/TLS): the encrypted version on port 636, protecting credentials in transit. - Distinguished Name (DN): the unique path to an object, for example "CN=John Doe, OU=Users, DC=example, DC=com".

Federated Identities Federation links identities across organizations, forming a circle of trust between a Service Provider and an Identity Provider. - Identity Provider (IdP): creates and manages identity information (for example Okta or Microsoft Entra ID). - Service Provider (SP): hosts the application the user wants and trusts assertions from the IdP. - Trust relationship: a pre-arranged agreement letting the SP accept authentication tokens from a specific IdP.

Authentication and Authorization Protocols SSO relies on standard protocols to pass assertions and tokens. - SAML (Security Assertion Markup Language): an XML framework for web-based SSO that carries authentication and authorization data in "assertions." - OAuth 2.0: an authorization framework that lets a third-party app access resources without ever seeing the user's password. - OpenID Connect (OIDC): an authentication layer on top of OAuth 2.0 that uses JSON Web Tokens (JWT) to verify identity.

Quick recall - LDAP ports → 389 (cleartext) vs 636 (secure, LDAPS). - SAML → XML-based; best for enterprise web SSO. - OAuth → token-based; delegated authorization. - OIDC → adds authentication on top of OAuth 2.0. - Trigger: "log into a third-party site with your Google account" → federation via OIDC.