[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] SAML/Shibboleth Context in attribute queries
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC