[security-services] SAML/Shibboleth Context in attribute queries

[Marlena Erdos <marlena@us.ibm.com>]

SAML colleagues,

Introduction/

In Shibboleth, the request for an attribute assertion includes an
element currently not defined in the SAML schema. Specifically,
the destination that the user has contacted provides the "context"
of the user's request.  In Shibboleth, this context is specifically
the URL that the user wishes to access.

This note includes first a suggested change to the protocol schema that
would allow for the addition of context information in an
attribute assertion query. It then provides rationale for
why Shibboleth needs this information.


Requested Schema Change/

Here is the schema for the attribute query with the suggested change
marked "NEW!!".

<element name="AttributeQuery" type="samlp:AttributeQueryType" />
  <complexType name="AttributeQueryType">
  <complexContent>
    <extension base="samlp:SubjectQueryAbstractType">
          <sequence>
              <element ref="saml:AttributeDesignator"
                                 minOccurs="0" maxOccurs="unbounded" />

        NEW!! <element name=saml:AttributeQueryContext" type="string"
                                 minOccurs="0" maxOccurs="unbounded" />

          </sequence>
          <attribute name="CompletenessSpecifier"
                                 type="samlp:CompletenessSpecifierType"
                                 use="required" />
     </extension>
 </complexContent>
 </complexType>



Rationale for Requested Change/

Most of this rationale seems to pertain to Shibboleth
however the application (so to speak) is broader:
it applies (IMO) to any destination that is trying to provide SAML-based
access to legacy applications  without actually recoding these apps.
   Such sites will typically create "n-tier" architectures with
SAML-accepting front ends, glue servers in the middle, and legacy resource
managers at the back-end.

Here though is the Shibboleth-oriented rationale (liberally derived
from the Shibboleth Architecture document that Scott
Cantor and I wrote. The architecture doc is available at
http://middleware.internet2.edu/shibboleth  ).


Shibboleth's design is motivated by the privacy considerations
that universities face. Uiversities in some countries (including the US)
are legally required to protect the privacy of their students.
These legal requirements sometimes dictate that a student be able
to access learning resources without revealing their identity.

Since Shibboleth is concerned with user privacy, an important element
of the Shibboleth architecture is the component that releases information
about users. This is the Attribute Authority (AA). Each origin site
(i.e. a site with administrative authority over users who access resources
at remote providers) has its own AA. The AA's job is to provide attributes
about a user to a resource provider.But the AA also has the responsibility
of providing a means for users to specify exactly which of their allowable
attributes gets sent to each site they visit.

For example, faculty member Mary Smith at Brown University may be a
participant of a multi-institution research project whose documents and
resources are located at Ohio State. And she may wish for personal
reasons to visit a multiple sclerosis site also hosted at Ohio State.
In the case of the research project, she may wish and need to send her
name to get access to project resources; in the case of the multiple
sclerosis site she may need only to send her affiliation (i.e. faculty
member at Brown University), and she may want to exclude the release of
her name.

The AA at Brown is responsible for providing a means for Mary
Smith to specify which of her authorization attributes get
sent where.  We call these specifications "attribute release
policies."

An attribute release policy consists of the identity of the
attribute requestor, the resource the user is trying to reach (e.g.
the URL of the multiple sclerosis site), and the attributes
that should be released to this identity/URL combination.

Note that in the example, a single entity will be handling the
SAML protocol to acquire attributes about the user, and will
be passing them to the two different resource managers that
control (respectively) the research project resources, and
the multiple sclerosis resources.
   In Shibboleth, it is the responsibility of this entity
(called a "Shibboleth Attribute Requester (SHAR)"), to
notice when the user surfs across application boundaries
and to re-request attributes so it sends the "right ones"
to the resource manager.


Summary/

Shibboleth needs to provide "context" information
in an attribute query to support selective attribute
release to destinations that host multiple resources
behind a single SAML-ized protocol engine.

A simple way to incorporate this into SAML's attribute
query has been suggested (in XML) above.


Thanks,
Marlena