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: [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