Chad La Joie Shibboleth’s Future

2 © 2009 SWITCH Where are we now? Current releases: –Discovery Service –IdP –SP Shibboleth 1.3 classified as “previous stable release” –fixes for security issues, no new features, limited on-list support –end of life on June 30, no support after this time Java 5 end of life was October 30, 2009 –no plans to require Java 6 but we reserve the right to do so Moving to Jetty 7, away from Tomcat, as preferred Servlet container –still compliant with Servlet 2.4 spec so IdP/DS will still work in Tomcat

3 © 2009 SWITCH Next Major IdP Release Shibboleth IdP 3.0 is next major release –main goal: clean up APIs hindering new work –2.x configs will automatically be updated to 3.x configs during install –3.0 is not a major rewrite Major new features –distribution option that includes configured servlet container –clustering option that does not require separate install/config –N-Tier delegation support –integration of uApprove (attribute release consent) in to core code About a dozen or so minor features

4 © 2009 SWITCH Post-3.0 IdP Single log out support –working plugin developed by NIIF, the Hungarian NREN SPNEGO authentication support –no login required at IdP once you log in to a Windows domain Non-browser use case support –initial focus on username/password and X.509 authentication Configuration tools IdP user interface –IdP-initiated SSO/SLO –persistent ID disassociation –removal of attribute release consent

5 © 2009 SWITCH Shibboleth + Buzzwords: User-centric Identity Claim: All data about a person is property of that person and, as such, should be kept and controlled by that person –allows freedom of movement from provider to provider –allows a consistent identity across sites –allows individuals to choose what information they release to whom In practice though: –user isn’t authoritative for most of their data –self-asserted data is inherently non-verifiable (in-band) –a consistent identity across sites allow for correlation attacks –users can’t operate identity providers and so end up locked in to that provider The goal should probably be to bring information release consent to organization-centric identity –e.g. Shibboleth + uApprove

6 © 2009 SWITCH Shibboleth + Buzzwords: OpenID OpenID (OID) claims to be simple, user-centric, SSO –user’s have an OID provider that they run –OID is a URL entered at the SP (removes the need for a WAYF/DS) –authenticate via a process similar to Shibboleth 1 –proves ownership of a URL –white/blacklist based trust system Usage litmus test: Would you be willing to give out the restricted information to a random person who asked? –this is perfectly okay for many sites Shibboleth OpenID provider: –uses metadata as basis of trust/security (on by default) –attribute exchange (off by default) with attribute filter and release consent –OpenID support off by default because of the inherent insecurity of OpenID

7 © 2009 SWITCH Shibboleth + Buzzwords: OAuth OAuth is an access delegation protocol –You log in to service B. Service B wants your information from service A. You log in to A, get a token, give it to B. B uses the token to get your information from A. OAuth is independent of the means by which a user is authenticated or the format of the token –OAuth is orthogonal to federated identity management –so no real connection with Shibboleth OAuth is currently under-specified –creating interoperable systems tends to be a trial-and-error exercise –there are many, different, protocol flows that all claim to be OAuth –IETF WG attempting to provider a more clear standard

8 © 2009 SWITCH Shibboleth + Buzzwords: Cardspace CardSpace generally refers to two things: –Microsoft’s (MS) evolution of Passport in to a decentralized service  known by MS not as CardSpace but as the Identity Metasystem –MS’s client for the Identity Metasystem  this is what MS means when it says CardSpace Primarily focused on avoiding phishing –the operating system controls the UI during authentication Secondary focus –support for multiple authentication methods: SAML, OpenID, Kerb –support for user-centric identity through unmanaged cards –support for organization-centric identity through managed cards CardSpace is a client without a server Shibboleth Inforcard plugin provides a server

9 © 2009 SWITCH Shibboleth + Buzzwords: Geneva (ADFSv2) Server-side implementation of Identity Metasystem –non-interoperable successor to Active Directory Federation Services Appears to integrate with Exchange and Sharepoint Currently available released does not interoperate with other products –not using published CardSpace protocols –not compliant with standard specifications (XML DSIG/ENC, SAML) Shibboleth and Geneva –interoperation will require MS to publish the protocols in use –lack of meaningful metadata support will make running Geneva within a federation very work intensive