Federation made simple Project Ipsilon Pr Pr Pr Federation made simple Presented by Rob Crittenden Principal Software Engineer, Red Hat, Inc. Licensed under Creative Commons Attribution license http://creativecommons.org/licenses/by/3.0/.

Meet Joe An average guy

Joe likes the Web Typical web authentication example.org User DB Typical web authentication Username and password via a form Standalone user database

Joe likes the Web, a lot! site1 User DB User DB site2 User DB site3 User DB Whoa, that's a lof of username/password combinations site4 User DB

The Problem? Multiple passwords Some almost certainly bad Possible re-use Remembering which password goes where Reliance on each web site protecting its user database Go to a web site Presented with username/password login form Authenticate against local database Database usually specific to this one application

One solution: Federation Good for Joe: One account* to use everywhere So one password, hopefully a good one Still rely on 3rd party to protect data Good for Web Applications: Can support additional authentication methods Reduce administrative overhead No user database to manage* Things like LastPass can mitigate, but you still have separate identities everywhere These depend on the type of Federation used, centralized (SAML) or decentralized (OpenID). You may in fact want different identities but you control them, not the sites you use Multiple authentication mechanisms Username/Password OTP Biometrics SSL Kerberos Whatever

Generic Federation Generic overview Identity User Provider DB 4. Token 3. Auth Generic overview 1. Request example.org 2. Redirect

Not Federation No control of credentials example.org passwordsrus.org

Federation Highlights Trust a third party to do the authentication Generally a HTTP-based protocol Doesn't always require a browser, e.g. rich mobile client Cookies for state Centralized or Decentralized Common examples: SAML, OpenID and OpenID Connect Think LastPass but you only need one account for everything

SAML 2.0 Centralized XML and SOAP over HTTPS Requires agreement between parties Exchange of metadata and public keys Cross-Domain Single sign on and Single logout Security Assertion Markup Language Enterprise-oriented. The organization tends to own the Identity Provider. Stable: 2.0 finalized in 2005. Last updated 2012. The IdP can be exposed to provide authentication to 3rd party services (e.g. hotel/airline booking) Cross domain because the IdP does all the auth, not the SP SSL not strictly required but tokens would be exposed

How does SAML work? SAML has profiles, this is HTTP Redirect SSO IdP 3. Authenticate 4. Issue Token Joe SAML has profiles, this is HTTP Redirect SSO User requests secured page on Service Provider SP redirects user to IdP to authenticate. Session created on SP. User authenticates. Session is created on IdP. User redirected back to SP No direct communication to IdP from SP Sessions on the IdP allows for Single Logout 5. Redirect to SP 6. Redirect back to SP 2 Redirect IdP SP 1. Access SP

SAML Single Logout SAML has profiles, this is HTTP Redirect SSO 5. Complete SP1 logout IdP Joe 3. Find all sessions 2. Redirect to IdP 4. Logout SP 2 using SOAP 1. Logout SAML has profiles, this is HTTP Redirect SSO User requests secured page on Service Provider SP redirects user to IdP to authenticate. Session created on SP. User authenticates. Session is created on IdP. User redirected back to SP No direct communication to IdP from SP Sessions on the IdP allows for Single Logout SP 1 SP 2

OpenID Decentralized Identity is a URL You prove that you own that specific URL Like SAML, need to trust 3rd party to prove authentication Or, if you want, you can run your own OpenID server The Identity Provider can be anywhere. You can even own it. Consumer-oriented

OpenID An OpenID Identity itself tells very little about the user The user can select what information to provide (aka consent): Name E-mail Groups Whatever

How does OpenID work? rcritten.id.fedoraproject.org Site fetches HTML to discover provider Establish shared secret Redirect to Identity Provider to authenticate Redirect back to site OpenID itself doesn't set cookies

Where does Ipsilon fit in? Implements Identity Provider and Service Provider (e.g. server and client) Simple installation scripts Metadata exchange straightforward Configure attributes and naming per-SP Management GUI Plugin Framework Supports FreeIPA as identity source mod_auth_mellon mod_auth_openid

Administration GUI for admin

Provider plugins Provider == Federation protocol SAML IdP Lite conformance OpenID FAS extension Mozilla Persona IdP Lite No IdP Discovery Managed Name Identifiers (sync ID between IdP & SP)

Login mechanisms GSSAPI (Kerberos) Form auth (mod_intercept_form_submit) LDAP PAM FAS Can either rely on Apache to authenticate and set REMOTE_USER Or do the authentication itself, like LDAP and FAS plugins

Information Providers Source of identity attributes for a user By default: groups, mailing address, telephone, e-mail SSSD InfoPipe LDAP nss (POSIX info) Data visibility configurable on a per-SP basis Attributes to provide Name of those attributes

Ipsilon Demo Time

Roadmap OpenID Connect IdP Portal Expanded REST interface Additional SAML Profiles

More Information Home https://fedorahosted.org/ipsilon/ Source: git clone https://git.fedorahosted.org/cgit/ipsilon.git/ Patches: https://pagure.io/ipsilon IRC: irc://freenode.net/#ipsilon

Questions? rcritten@redhat.com Contact: Licensed under Creative Commons Attribution license http://creativecommons.org/licenses/by/3.0/.