Second use case for the delegation/tiered model

[Scott Cantor <cantor.2@osu.edu>]

I took an AI on the focus call to provide another use case that would tie in
more directly with SAML and the SSO profile issues.

Library Meta-Search

The Shibboleth community has been discussing a new distributed application
emerging in digital library access called meta-searching.

The Use Case

Online journal and resource providers offer a search function to their users
for finding resources in their collections. These search facilities are
being turned into SOAP-based services so that a new kind of searching
application can be developed that interacts with a browser user to obtain
search criteria and then applies the search to many resource providers using
their SOAP interface. This exactly matches the basic model described in the
draft.

The intermediate is a meta-search service that provides access to standard
browsers (for users that subscribe to the service) and communicate on their
behalf to the search services offered by individual resource providers. The
intermediate-backend protocol is SOAP, usually over HTTP.

Some of the security needs of the resource providers are provided by a
SAML-based federation that supports the use of the browser profiles to
access some of their services, in conjunction with SAML attribute
authorities. Thus, a trust fabric for evaluating assertions exists, and
security policy on the basis of SAML attributes exists.

The security arrangement between the intermediate and the back-end requires
both that the intermediate authenticate itself to the back-end and
demonstrate the right to access the back-end on behalf of the end-user by
temporarily assuming possession of a set of SAML attributes. There might
also be a requirement to provide user authentication information to
demonstrate presence.

Issues and Candidate Solutions

The SAML browser profiles permit the end-user to establish a SAML security
context with the meta search service and provide a means of obtaining SAML
attributes for the user, either via push or pull. These attributes would
typically be carried in a separate assertion from the SSO authentication
statement to allow for a longer validity period. However both assertions may
contain a NameIdentifier that cannot be exposed to another entity, a common
privacy requirement in library applications.

If the contents of the NameIdentifier are not significant to the back-end,
then the element could be encrypted for the intermediate service, allowing
it to properly associate any assertions with the user's security context
while permitting it to forward them to the back-end.

A single attribute assertion could potentially be used by both the
intermediate and back-end, although if many back-ends were being contacted,
this could lead to leakage of attributes. The intermediate could communicate
its needs to the SAML authority so that multiple assertions could be
created, or even obtain encrypted attributes for the different back-ends.

If a stronger confirmation than "bearer" were required, then the
intermediate could perhaps request that its key be included in the attribute
assertion(s) as a confirmation key so that it could utilize TLS or the WSS
SAML token profile to attach the token to its SOAP requests. This would be a
more controlled impersonation of the user's attributes.

If demonstration of user presence were required, then the intermediate might
need to obtain an authentication assertion for the user with a
NameIdentifier that was semantically relatable to the attribute assertion it
presents to the back-end. It is conceivable that this could be done by
simply encrypting the NameIdentifier in the original SSO assertion and
enabling the intermediate to forward it.

In the existing browser profiles, there are no clear security concerns being
met by the short validity period of the assertion, because the "packaging"
of the assertion request or delivery process in both profiles independently
enforces the short-lived constraint. However, current SAML practice is not
to sign the SSO assertion, and it is therefore not a forwardable token.

Obviously, the intermediate could obtain a second authentication assertion
that would be forwardable to the back-end.

-- Scott