OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [security-services] SAML/Shibboleth Context in attribute quer ies


I promised to comment on this proposal so I will.

I do not object to the addition of a catch-all string element to qualify the
identity of the requestor for privacy purposes. I would prefer a more
descriptive name, such as "Requester-subdomain", but I do not insist on it.

My concerns are more about how Shib intends to use this, which I suppose is
none of my business. As I understand the intention, there is a single entity
making requests on behalf of sub-entities, which need to be distinguished
from each other for the purposes of releasing attribute information. The
proposed method is to include the full URL of the user request to which this
information will be applied.

In my opinion, it would make more sense to identify these sub-entities by a
meaningful name such as their ordinary name, e.g. "National Multiple
Sclerosis Society" or top level dns domain, e.g. nmss.org.  A text name
could remain stable as organizations merge or reorganize and in the face of
technical restructuring of the network. A top level dns name would be a
little less stable, but at least would allow the privacy policy to set in a
suitably granular way.

Certainly this would be much easier for the user who wants to set up their
privacy policy as described in the example. In fact, I don't really see how
this scheme can be made practical without using some kind of wildcarding in
the privacy policy specification. You don't really plan to have Mary enter
all the URLs she might access and enter a privacy policy for each do you?

Another objection to the URL scheme is based on privacy. It leaks
information about the usage patterns of end users. I do not know if this is
a problem in any particular case, but it would seem in the interests of
privacy to distribute just the information needed to do the job and no more.

Since the proposal to SAML is just a text field, individual depolyments are
free to use it in a sensible way or not.


> -----Original Message-----
> From: Marlena Erdos [mailto:marlena@us.ibm.com]
> Sent: Monday, October 15, 2001 9:12 PM
> To: security-services@lists.oasis-open.org
> Cc: Ken.Klingenstein@Colorado.edu; Steven_Carmody@brown.edu;
> david.wasley@ucop.edu; hazelton@doit.wisc.edu
> Subject: [security-services] SAML/Shibboleth Context in attribute
> queries
> Importance: High
> 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
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC