Shibboleth 2.0: 6 months later…Shibboleth 2.0 -- Again

Nate Klingensteinndk@internet2.edu

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

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

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?

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

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

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!

1.3 SP Internal Architecture

In process (native) Out of Process (shibd)

Request Map

Metadata

Trust

AAP

Applications

Handlers

Session CacheBacking

Store

Configuration

Metadata

Trust

AAP

Applications

Client

Listener

Server

Listener

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?

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

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

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

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?

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

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

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

Shibboleth 2.0 IdP

• Protocol Handlers

• NameIdentifier

• Attribute Resolution

• Authentication

• Levels of Assurance

1.3 IdP Internal Architecture

Servlet

Container IdP

Responder

Config IdP Protocol SupportNameID Map.

Credential P.

Metadata P.

Trust Engine

ARP Engine

Attribute Reso.

Artifact Map.

AA Attribute

Protocol

Handler

Protocol

Handler

Protocol

Handlers

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

IdP: Protocol Handlers

<IdP>

<ProtocolHandler Location="expression">

<Binding="urn....."/>

<Binding="urn....."/>

</ProtocolHandler>

<ProtocolHandler Location="expression2">

<Binding="urn....."/>

</ProtocolHandler>

</IdP>

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.

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?

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

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

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

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

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

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

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

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

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

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

More Information

https://shibboleth.internet2.edu

https://authdev.it.ohio-state.edu/twiki

/bin/view/Shibboleth/WebHome

ndk@internet2.edu