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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Chadwick paper on Grid use of SAML AuthzDecisionQuery/Response

Anne H. Anderson       Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
Burlington, MA         781-442-0928
--- Begin Message ---

the paper will be on the web site on Monday (barring any hickups). the
url is


then you will find it under Conference Proceedings, (All hands at


 p.s. I will answer your points next week

Anne Anderson wrote:
> On 17 August, David Chadwick writes: Re: AuthzDecisionQuery/Resp Working Session at SAML F2F?. Forwarded  message from Philpott, Robert.
>  > Please find attached a paper that I have just written for the UK Grid
>  > All Hands meeting due to take place the first week in September. The
>  > paper describes the current Grid SAML authorisation interface (in
>  > non-normative terms and as jargon free as possible), plus it gives
>  > rationales and requirements for all the features of SAML that are being
>  > used as well as the extensions that are being proposed. It should
>  > provide useful background reading to our phone conference next week.
>  >
>  > Bye the way, if you spot any errors in the paper please let me know, as
>  > I plan to send it to the conference organisers on Sunday
> Very interesting paper!  This will be helpful to people trying to
> understand Grid proposals that affect SAML and XACML.  Once you
> have a stable URL for this, please let me know so I can post it
> to the XACML TC mailing list.
> Comments:
> 1. Introduction, paragraph 2
>    "the authorisation mechanism needs to be distributed"
>    It is not completely clear whether this means policy
>    issuers/owners need to be distributed or whether PDPs/ADFs
>    need to be distributed.  If a Grid has a single broker that
>    acts as the PDP/ADF, then the broker might collect distributed
>    policies but not itself be distributed.  For scalability,
>    however, it is good for the policy evaluation engine to be
>    distributed, especially if it is defined in a stateless
>    manner.
> 2. Authorisation Infrastructure Requirements
>    This section talks about standardizing the interface between
>    the PEP/AEF and the PDP/ADF (i.e. the
>    AuthorizationDecisionQuery).  I think the interface between
>    the policy issuers and the PDP/ADF (i.e. the policy language)
>    is just as important for standardization.  XACML specifies a
>    standard policy language (although not a transport), as well
>    as specifying a standard for the interface between the PEP/AEF
>    and the PDP/ADF.
> 3. Authorisation Infrastructure Requirements, paragraph 2
>    "Examples of authorisation APIs are ...".
>    The Java Policy API
>    (http://java.sun.com/j2se/1.4.1/docs/guide/security/spec/security-spec.doc.html)
>    is probably the most widely used of any such APIs, so should
>    probably be listed here.
> 4. Authorisation Infrastructure Requirements, paragraph 5
>    "a simple Boolean is sufficient"
>    XACML, for very good reasons, decided that two additional
>    cases were important: unable to answer due to lack of
>    policies applicable to this request, unable to answer due to
>    an error.
>    The OGSA case of "answer, subject to further conditions" is a
>    good one, and XACML/SAML should include coverage for it.
> 5. Authorisation Infrastructure Requirements, paragraph 5
>    "However, if the client is a user, who then wishes to forward
>    the response to an AEF/PEP..."
>    As I was reading along, this seemed like a completely new
>    model for the authorization infrastructure.  Perhaps the first
>    paragraph in this section should discuss the overall model
>    abstractly in a way that can include this use case.
> 6. Authorisation Infrastructure Requirements, 1st numbered list
>    Item 2) gives as example "write access to file Fred", but the
>    item mentions only "operations/actions".  Perhaps the example
>    should be "write access", with "file Fred" being covered in
>    item 3) as a target resource.
> 7. Authorisation Infrastructure Requirements, 1st numbered list
>    Item 4) mentions "access is granted up to 3 megabytes of
>    storage".  If this is for a single request, then the PDP/ADF
>    can remain stateless.  If, however, this is intended to cover
>    a total of 3 megabytes over multiple requests, then it implies
>    either that the PDP/ADF must maintain state (not scalable), or
>    that the client must maintain state and pass that along with
>    the request.  This would require an additional "category of
>    information" to be passed.
> 8. Authorisation Infrastructure Requirements, 2nd numbered list
>    It is not immediately obvious to the reader that this 2nd
>    numbered list is intended to parallel the 1st numbered list.
>    In this context, Item 4) looks like a typo.  It just says
>    "(there is no default for this)".  Suggestion: say "We attach
>    the following default values and meanings to the items in the
>    previous list:"
> 9. Authorisation Infrastructure Requirements, paragraph following
>    2nd numbered list
>    "When conditional responses are returned, the AEF/PEP is
>    actually being asked to perform some of the functionality of
>    the authorisation server, i.e.. evaluate some of the policy
>    conditions that grant or deny access..."
>    I view this differently: the AEF/PEP is being given a partial,
>    optimized decision containing a "policy" (i.e. condition) that
>    the AEF/PEP can then pass again to a PDP/ADF for evaluation
>    within a specific context.  It may pass the policy to the same
>    PDP/ADF or to a different PDP/ADF.  I agree that this behavior
>    should not be mandated.
> 10. Authorisation Infrastructure Requirements, last paragraph
>    "(categories 1 and 5 in the list above)"
>    "(categories 2, 3 and 4 above)"
>    There are two lists above (parallel), so perhaps these should
>    say "(categories ... in the first list above)".
> 11. Authorisation Infrastructure Requirements, last paragraph
>    Multi-step decision-making
>    I still believe this concept as used here is conflating two
>    architectural entities that should remain separate: attribute
>    authorities and decision functions.  There should be two
>    separate SAML queries, each addressed to the appropriate
>    entity: AttributeQuery and AuthorizationDecisionQuery.
>    Stateful PDPs (although these do not scale, and thus should
>    not be encouraged) might cache attributes passed in requests,
>    or obtained as part of evaluating requests, while still not
>    providing "multi-step decision making".
>    There is a 3rd type of query that is relevant: "what
>    attributes must I provide in order to access resource X?"
>    This query is asking a very different question from an
>    AttributeQuery: the new query asks for the identities of the
>    attributes needed (and possibly the acceptable value ranges),
>    while an AttributeQuery asks for authenticated attributes with
>    values assigned to a particular subject/user.
>    The XACML Profile for Web Services defines an entity that is
>    intended to respond to this 3rd type of query.
>    Separating the various types of queries will make the
>    interfaces being defined much simpler.  Currently, multiple
>    AuthorizationDecisionQuery modes are being defined.  Good
>    interface design reduces modes.
> 12. 4.1 The SAML Authorisation Decision Request, 3rd paragraph
>    "If the client wants to learn about the access rights of the
>    user to all resources known to the authorisation server..."
>    [same arguments apply to "all actions known..." in the next
>    paragraph]
>    Does this mean a single decision, which would be "true" or
>    "Permit" only if the client has access rights to every
>    resource?  Or does it mean return multiple decisions, one per
>    resource?
>    Does this mean that the PDP/ADF must know a set of resources
>    individually, or does it mean that the PDP/ADF will respond in
>    terms of how the resources are referenced in its policies?
>    For example, if the policy says "Anne has access to all files
>    in the directory subtree
>    file:/net/sydney.east.sun.com/home/aa74233/", does the
>    response to "any" return exactly this, or does it query the
>    resource for (or "know") the list of subdirectories and files
>    in that subtree, and return that list?
>    Expressing requests and policies that refer to subtrees of a
>    hierarchical resource like a file system are difficult
>    problems, particularly where the permissions for one part of
>    the subtree depend on permissions associated with another part
>    of the subtree.  The XACML TC has spent a lot of time on this,
>    and every solution so far has been shot down with good
>    arguments for why it does not work.
> Anne
> --
> Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> Burlington, MA 01803-0902 USA  Fax: 781/442-1692


Leaders of the world's richest nations meet in Cancun on September 10th
2003. Oxfam is presenting them with a petition to make trade fair. Be
sure your voice is heard. Sign the 'Big Noise' petition to make trade
fair at:



David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@salford.ac.uk
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
org:University of Salford;IS Institute
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
fn:David Chadwick
--- End Message ---

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