SAML-based Delegation in Shibboleth Scott Cantor Internet2/The Ohio State University

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

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

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

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

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

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

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

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

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

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