MHonArc v2.5.0b2 -->
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
------
Anne H. Anderson Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
Burlington, MA 781-442-0928
--- Begin Message ---
Anne
the paper will be on the web site on Monday (barring any hickups). the
url is
http://sec.isi.salford.ac.uk/Papers.htm
then you will find it under Conference Proceedings, (All hands at
Nottingham)
regards
David
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:
http://www.maketradefair.com/go/join/?p=omf1
*****************************************************************
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
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
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
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard
--- End Message ---
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]