1. SAML-based Delegation in Shibboleth Scott Cantor cantor.2@osu.edu Internet2/The Ohio State University

2. Quick History Shibboleth announced for browser-based authentication to web sites, first lines of code written Next day, first post to mailing list asking about web services

3. Change in Direction Architectural emphasis in SAML / WS-* is on message-based security and SOAP Developers want session-based security and REST

4. Technical Requirements HTTP-based services (SOAP or REST) Security no weaker than browser-based SSO (i.e., bearer tokens) Evolutionary path to stronger security based on private keys controlled by delegates Attribute-based Federated Privacy-capable (hide user information from delegate) Standards-based where possible Application transparency

5. SAML-based Solution Leverage SAML 2 Enhanced Client / Proxy SSO profile in place of Browser SSO profile between delegate and web service Leverage WS-Security and WS-Addressing profiles between delegate and IdP, influenced by or directly reused from Liberty Alliance work

6. Identity Provider Enhancements Assertions issued for SSO optionally extended such that a delegate can authenticate back to IdP as user SAML 2 ECP SSO profile using extended assertion + SSL client auth Policy controls: Which SPs can be delegates What WSPs an SP can access as delegate Length of delegation chain Attribute release based on use of delegation

7. Service Provider Enhancements Decision made to "break" existing applications if a delegated assertion presented Revamp policy and SSO profile code to make assertion evaluation easily extensible (e.g., accepting delegated assertions) Expose delegation chain to applications via SP-defined header/variable

8. Application Changes Targeting applications using Shibboleth SP for authentication Disallow delegation: no changes Accept but ignore: add policy rule to SP configuration Accept and process: add policy rule and process chain from header/variable

9. Phase II Initial prototype treats portal and portlets as a single security principal/identity in chain Technical proposal allows for portal to acquire new tokens on behalf of portlets to give them presence in final token Requires stand-alone token exchange between portal and IdP

10. Phase III Holder of key adaptation of ECP, binding delegation token to delegate's client certificate If necessary, support for message signing between delegate and IdP as alternative to SSL client authentication

11. A Note on OAuth As in, why not OAuth? Feel free, what's stopping you? OAuth relies on a service to define its own security token; you don't need Shibboleth or SAML if that's your model You do need capability to redirect client to the service