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:
Ireland http://www.baltimore.com