[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] spec text for additional Attribute Query element
In the message http://lists.oasis-open.org/archives/security-services/200110/msg00087.html of 2001-10-15, Marlena Erdos proposed the addition of an additional schema element to the SAML attribute query. We discussed this in some detail at the Nov 13-14 F2F and took a vote to include it, pending the creation of more explanatory text regarding the element that would be included in the SAML spec. This note provides the requested text. This proposal is specific to the inclusion of context in attribute queries, and does not address broader, more complex, use cases in which arbitrary context might be useful, such as in authorization decision queries. The requirements for that are sufficiently different as to warrant a separate proposal (if desired by others in the committee). Marlena's note provides extensive rationale for the element, in terms of meeting Shibboleth requirements. At the F2F we tried to justify it in more general terms. Here is an attempt at writing that down. Consider the exchange between a requester Q, which generates a request containing an AttributeQuery (core-20, section 2.4.1), and a responder R which responds with an assertion containing an AttributeStatement (core-20, section 1.6.1). When preparing its response, R can take into account these aspects of the request: Subject: Obviously the main thing. Identity of requester: Though not a distinguished schema element, presumably in most situations the request would be authenticated via a security mechanism in some binding. This permits the responder to apply access control to returned attributes based on the identity of the requester. Requested attributes: Via the Attribute element in the query the requester can indicate its interest in having particular attributes be returned. (Obviously R can apply whatever other policy it wants as well.) The use of the items above can support reasonable optimization and least-privilege: the requester can ask for just what it wants, and the responder can restrict the attributes it provides to only those the requester is allowed to see. However, there is a system design that we think is likely to occur often that it doesn't support well, and that is where a number of "application domains" (ie, entities about which distinct policy might be set about which attributes should be used) make use of a single requester (ie, a single requesting identity). This kind of system could exist for many reasons: the typical "portal" scenario; a single web server supporting applications for different departments in an organization; a single web front end for several distinct non-web backend systems. In this situation we would like the responder to base its response not only on the requester identity but in which application domain the attributes will be used. Clearly it would be possible to always deploy systems such that each distinct "application domain" is represented by a distinct requesting identity. However, this imposes what seems to us a needless burden on application deployment, e.g. having to generate and manage a separate requester client certificate for each application behind a portal. It is very useful, instead, for an attribute query to contain an additional element, other than subject and requester, specifying further context that the responder can use to decide which attributes to respond with. We propose that support for this element is optional (ie, a conforming implementation doesn't have to support it), so this feature should not unduly affect attribute responder implementations that do not wish to support it. A responder that wishes to ignore the element can do so, and return attributes just as if the element weren't present. A responder that wishes to reject use of the element can do so by responding with the proposed error code. Proposed schema and text is below (lines based on core-19). The reference to a SAML status is of course preliminary, pending final design of SAML status codes. In the AttributeQueryType type definition, add the following attribute before line 918: <attribute name="Resource" type="anyURI" minOccurs="0"/> Before line 907, add the following text: <Resource> [Optional] The <Resource> attribute specifies the URI of a resource which is relevant to the request for attributes. If present, the responding entity MAY use the information in determining the set of attributes to return to the requesting entity. If the responding entity does not wish to support resource-specific attribute queries, or if the resource value provided is invalid or unrecognized, then it SHOULD respond with a SAML status of "Error.Server.ResourceNotRecognized". - RL "Bob" Morgan Scott Cantor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC