1. Shibboleth 2.0: 6 months later…
Shibboleth Again
Copyright Nate Klingenstein, This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.
Nate Klingenstein

2. The New Timeline OpenSAML 2.0 Technology Preview 2 Shibboleth 2.0
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. 1.3 SP Internal Architecture
In process (native)
Out of Process (shibd)
Request Map
Client
Listener
Server
Listener
Handlers
Metadata
Trust
AAP
Metadata
Trust
AAP
Session Cache
Backing
Store
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 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 ODBC-based session/assertion cache
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. 1.3 IdP Internal Architecture
NameID Map.
Servlet
Container
IdP Protocol Support
Config
Credential P.
IdP
Responder
Metadata P.
Protocol
Handler
Handlers
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
<ProtocolHandler Location="expression">
<Binding="urn....."/>
</ProtocolHandler>
<ProtocolHandler Location="expression2">
</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
Modular authentication != modular credential collection or validation

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. https://authdev.it.ohio-state.edu/twiki /bin/view/Shibboleth/WebHome
More Information
/bin/view/Shibboleth/WebHome