1 / 9

Shibboleth’s Future

Shibboleth’s Future. Chad La Joie (chad.lajoie@switch.ch). Where are we now?. Current releases: Discovery Service 1.1.1 IdP 2.1.5 SP 2.3.0 Shibboleth 1.3 classified as “previous stable release” fixes for security issues, no new features, limited on-list support

marc
Download Presentation

Shibboleth’s Future

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Shibboleth’s Future Chad La Joie (chad.lajoie@switch.ch)

  2. Where are we now? • Current releases: • Discovery Service 1.1.1 • IdP 2.1.5 • SP 2.3.0 • 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, 2010 - 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 https://spaces.internet2.edu/display/SHIB2/IdPRoadmap © 2009 SWITCH

  3. 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 https://spaces.internet2.edu/display/SHIB2/ShibbolethBacklog © 2009 SWITCH

  4. 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 © 2009 SWITCH

  5. 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 © 2009 SWITCH

  6. 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 © 2009 SWITCH

  7. 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 standardhttp://www.ietf.org/dyn/wg/charter/oauth-charter.html © 2009 SWITCH

  8. 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 https://spaces.internet2.edu/display/SHIB2/Contributions © 2009 SWITCH

  9. 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 © 2009 SWITCH

More Related