[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 ---
- From: "D.W.Chadwick" <D.W.Chadwick@salford.ac.uk>
- To: Anne.Anderson@sun.com
- Date: 29 Aug 2003 22:41:39 +0100
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]