1. 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

2. Meet Joe
An average guy

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

4. 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

5. 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

6. 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

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

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

9. 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

10. 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 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

11. 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

12. 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

13. 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

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

15. 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

16. 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

17. Administration
GUI for admin

18. 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)

19. 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

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

21. Ipsilon
Demo Time

22. Roadmap OpenID Connect IdP Portal Expanded REST interface
Additional SAML Profiles

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

24. Questions? rcritten@redhat.com Contact:
Licensed under Creative Commons Attribution license