Shibboleth 2.0: 6 months later…

1. Shibboleth 2.0: 6 months later… Shibboleth 2.0 -- Again Nate Klingenstein ndk@internet2.edu

2. The New Timeline • OpenSAML 2.0 Technology Preview 2 • Released Sept. 5 • Shibboleth 2.0 • Spring ‘07 • Shibboleth 2.1 • TBD • Everything herein subject to heavy revision

3. Progress made since Athens • Functionality added to 1.3 • Security holes fixed • Endless ratholes explored • Face-to-face developers’ meeting Sept. 1-2 • The source of most of this information

4. SAML 2.0 Issues • SOAP, browser clients both supported • Noteworthy supported protocols & bindings: • SAML 2.0 AuthnRequest • SAML 2.0 AuthnResponse • SAML 2.0 SingleLogout • SAML 2.0 AttributeQuery in the IdP • Shibboleth/SAML 1.x POST and Artifact • ADFS • WS-Fed? • Noteworthy unsupported protocols & bindings: • SAML 2.0 Name Identifier Management • SAML 2.0 AttributeQuery in the SP?

5. Shibboleth 2.0 Principles • Incoming messages in SAML 2.0 and others can’t be identified until unpacking • Bindings are decoupled from protocols • Signing, multiple endpoints • If you leave the SP without identifying the IdP, you’re forced into Shibboleth 1.x flows • Configurations will not be compatible • High priority to keep the deployment bar low, and interoperability high • Keep everything as stateless as possible

6. Single Logout • The goal is not complete single logout • Log the user out of the IdP and a small number of highly secure applications • The IdP is the ultimate session authority • Responsible for notifying session participants • Responsible for most of the UI; SP handles UI if something breaks there • May still be SP-initiated • Front-channel browser & back-channel SOAP • SOAP greatly preferred, but does it need new endpoints? • Signing vs. TLS: Signing wins • Requires keys in the metadata • Prefer frames to imbedded images

7. The WAYF • No widely deployed client-based solution to the discovery problem(Cardspace) • WAYF becomes a discovery service • New flow: SP -> WAYF -> SP -> IdP • Create a new protocol for querying the WAYF • Send user, receive providerId • Cookie handling • Avoiding creation of a protocol translator • But you’re welcome to build one!

8. Session Cache Metadata Trust AAP Metadata Trust AAP Backing Store 1.3 SP Internal Architecture In process (native) Out of Process (shibd) Request Map Client Listener Server Listener Handlers Applications Applications Configuration

9. Shibboleth 2.0 SP -- New SP &SP Classic • General changes • C++ Changes • Refresh removed • ODBC caching • Attribute/assertion export • Java SP • Implementation • Installation & Application Mapping • Attribute/assertion export • Attribute resolver?

10. General SP • SAML 2.0 decouples bindings from protocols • Moving from a single SAML response model to a multiple assertion model • SAML SSO assertion will have multiple statements • Approach enables other protocols • Allows for things like “authentication upgrades” • And advanced attribute aggregation techniques • ID-WSF Flavored SAML queries or something similar • XML-based ShibSession • Collect additional assertions for existing sessions at runtime

11. C++ SP • Attribute refresh removed • What would happen to an application if the attributes changed midrequest? • Session lifetime is attribute lifetime • ODBC-based session/assertion cache • Session Initiation via providerId’s • TestShib uses this today • Most functionality remains out-of-process • In-process to out-of-process communication now XML-based

12. C++ SP • One-to-many path to handler relationship • In WS-* & SAML 2.0, until a message is unpacked, it’s not clear which handler to use. • Multiple endpoints still needed • Artifact vs. POST • On Apache, attribute export performed with subprocess environment variables instead of (still optional) HTTP header variables • Unspoofable • ISAPI and NSAPI? • Need to use the IIS Metabase eventually

13. C++ SP • Authentication information exported to apps: • Authentication method • NameID • Authentication context? • Header size limit makes exporting XML hard • We could develop a REST-ish interface (preferred) • Or chunk the assertions through headers • Historically, pass the attribute assertion • Not right to begin with, and getting more wrong • How do applications reference the assertions they want?

14. Java SP • Implemented purely as filters • No need to deploy servlets with your apps • Limited work to configure new applications • shibboleth.xml will differ by some amount • We don’t believe homogeneity is important here -- are we right? • Use Spring to load configuration • Distributed configuration with dependency injection

15. Java SP • State mostly server-side using session object • Limited client state possible because of SOAP/browser dual support • Attributes & assertions exposed as session object attributes • And maybe as header variables • Sanity checks on every request • An attribute resolver functionality embedded in the SP? • Bookmarks, preferences • Legacy names/logins

16. Java SP • Applications likely to be a different concept • More context in a servlet container • Bugs in Tomcat’s virtualization & canonicalization • Add a property to each application’s web.xml specifying hostname? Ugh. • If we don’t use web.xml, we’d use the C++ request mapping structure • Servlet 2.3 specification, hopefully

17. Shibboleth 2.0 IdP • Protocol Handlers • NameIdentifier • Attribute Resolution • Authentication • Levels of Assurance

18. Protocol Handlers Protocol Handler Protocol Handler 1.3 IdP Internal Architecture NameID Map. Servlet Container IdP Protocol Support Config Credential P. IdP Responder Metadata P. Trust Engine ARP Engine Artifact Map. AA Attribute Attribute Reso.

19. IdP: Protocol Handlers • Interface between the IdP Responder & the Protocol Handlers • Had been very SAML-based, will no longer be • 1.3 handlers match via regex, using the first found • But with multiple message types hitting a single endpoint… • The difference between browser, SOAP in authentication is particularly bad • We’ll implement a many-to-many mapping • Multiple handlers at an endpoint • Multiple endpoints per handler

20. IdP: Protocol Handlers <IdP> <ProtocolHandler Location="expression"> <Binding="urn....."/> <Binding="urn....."/> </ProtocolHandler> <ProtocolHandler Location="expression2"> <Binding="urn....."/> </ProtocolHandler> </IdP>

21. The NameIdentifier Quandary: how things used to be • An incoming message subject is mapped to a principal name • Performed up front so it can handle the request • Limitations arise from attribute query & other flows… • The principal name is used for attribute resolution, clear logs, etc. • But now NameIdentifiers are things we’ve been calling attributes.

22. The NameIdentifier Quandary: the theory • Unified internal representation of identity • Principals/users • Entities • Allows for issuance of assertions to anyone about anyone, e.g. SOAP clients • What’s the trust engine look like? Metadata? • Multiple parties in every request • Requester • Presenter • Relying Party • How can we do this without confusing everyone? • ARP’s • Other configuration • Which is most important? The requester?

23. The NameIdentifier Quandary: it gets worse • SP’s may request a specific name identifier • But maybe not: must have a default in the RelyingParty • Metadata may contain name identifier preferences • We’ve always treated metadata as a set of hints rather than rules • Federations represent groups of providers • What takes precedence? What do you send? How do you handle multiple results? • ARP’s are cumulative, NameIdentifiers singular • But ARP’s should apply; these are attributes, after all

24. The NameIdentifier Quandary: the last issue • Mapping can’t be up front anymore due to intensive processing • And you may need to go look it up in external stores • NameIdentifier is really the primary key amongst your attributes • Unification with the Attribute Resolver • Without hammering data stores • 50% of the current IdP request overhead is attribute resolution

25. Today’s NameIdentifier Solution • Resolve the NameIdentifier as far forward as possible • 5 minute secondary attribute cache to avoid hammering repositories, but maintain data freshness • IdP receives a request; needs to send out a NameID in the subject. • Look at the request; is one specified? ARP it • Look in the metadata; • If multiple matches, use order of precedence, and throw the leftovers into additional attributes? • If nothing in the metadata, use the default for the RelyingParty

26. IdP: Attribute Resolution • Make the attribute resolver and ARP engine more XML-aware • XPath for NameIdentifiers? • Implement Beanshell for attribute resolution? • SAML 2.0 LDAP profile uses urn:oid • We’d been doing lookup using friendly names • If you then map those back to OID’s, they may not correspond to the ones in the directory

27. IdP: Attribute Resolution • SAML 2.0 includes an attribute namespace as well as attribute name • We’ll always use the URI namespace, and so should you • But it’s different for Shibboleth 1.x and SAML 2.0… • Will probably be hardcoded • We’d assumed one namespace implicitly • Now attribute names have two parts • But we still will make this assumption for deployment sanity • Commercial vendors use namespace similar to our scope • For interop, Shibboleth will be able to receive multiple namespaces, but not send them

28. IdP: Authentication • Incoming AuthnRequests routed through handlers to arrive at a dispatcher • Inspects request • Evaluates whether authentication needs have already been met • Dispatched to another handler -- but how, and how do they get back? • Once you return the browser, you’re toast • Basic auth as a model? • Back-channel calls, shared cookie domains • isPassive

29. IdP: Authentication • Denial of Service fears • If we can’t store everything in the browser via cookie chunking… • Then we’re spinning up sessions prior to auth/n • SSO handler will pass to another layer of abstraction • IdP Responder -> SSO Handler -> Authentication Handler -> Authentication Mechanism • We’ll ship a Shibboleth ISO, which includes IP-based, and form-based netid/password for LDAP and database backends • Your solution plugs into the Authentication Handler spot

30. IdP: Authentication & LoA • Authentication Method • Purely technical • What’s “better” mean? • Authentication Context • Includes policy • SP can request multiple sufficient authentication contexts • How do you choose which one to use? • How can authentication contexts be ordered without leading to configuration pain? • SSH/SASL send back a list, but worry about downgrade attacks • Federal Government: NIST has defined LoA

31. General IdP • Would need to maintain many sessions in the IdP to handle SLO • One per principal • One per principal/relying party pair • Must be server side to support both SOAP and browser logout • Some sort of session interface needed; some may have less functionality, but will be easier to deploy • Cookie, file, database, in-memory, Sequoia, etc. • Logout support becomes optional

32. General IdP • More dynamic configuration • Changes picked up, tested, and loaded on the fly • New “Defaults” element to contain baseline response parameters • RelyingParty elements sit within this

33. More Information https://shibboleth.internet2.edu https://authdev.it.ohio-state.edu/twiki /bin/view/Shibboleth/WebHome ndk@internet2.edu