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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

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


Subject: Re: Requirement for Isolated Request for Authorization Atributes



Folks,

> Whether this is the domain of XACML or SAML, I'm not really sure. SAML should just be flexible
> enough to support an authorization decision that contains more than a yes/no decision.

I'd agree with that last sentence. I believe we do want a PDP to be able
to emit more than just "yes/no" as the response to an authorization 
decision request (note: I'm not saying whether the entity to which the
response is sent is defined as a PDP or PEP - matters of definition not
being interesting in themselves, I'll say PxP for now, do your favorite
substitution as you read:-). An example I'd give would be:

PxP -> PDP: "Is fred ok for /plubmers-only"
PDP -> PxP: "Yes, and btw fred is a plumber"

or, possibly a bit more complex, but better for interop:

PxP -> PDP: "Is fred ok for /plubmers-only and btw: tell me about his plumber-ness"
PDP -> PxP: "Yes, and btw fred is a plumber"

I think we do need to be careful though, since we are running the risk
of getting into the complexity of writing a generic authorization policy
language.

So, in addition to the yes/no decision we need to be able to provide some 
additional information in a limited fashion. My starting point would be to
limit that to a list of name/value pairs (in whatever syntax, but with "flat"
value syntaxes only) and simply assume that local configuration is required to 
determine when a PDP should emit which name/value pairs, i.e. if you need this 
feature a lot, you're probably losing some interoperability and limiting 
yourself to certain pairs of PDP, PxP implementations (at least at administration 
time, if not at run-time).

We should also attempt to do this in a way that doesn't conflict with the
putative XACML group. Note again: I didn't say "the same way", or "a 
compatible way", just "doesn't conflict", e.g. having to apply an XSLT 
transform to our simple name/value format to get to a schema-valid XACML 
document is just fine (especially since XACML doesn't yet exist:-). If 
the names and values SAML supports in this part of an authorization decision 
response message are basically simple strings, I think we're 100% certain 
that such a mapping will be possible, without waiting for XACML to even get 
started.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


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


Powered by eList eXpress LLC