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] | [Elist Home]


Subject: RE: XACML TC Charter Revision - Strawman


> maybe i am just being overly cautious., but my concern comes from the
> detail of the response. since security is composed of authentication,
> authorization and [encryption], i would prefer that failure of
> authorization be limited to a predefined list of failure 
> types to limit
> the exposure of one security aspect from antother. 'free 
> form' specifics
> may allow an intruder to determine which 'product' is being used to
> perform the authorization (kinda like how nmap generates os profiles
> based up network responses), and therby be able to apply a 
> known exploit
> selectively. there can be 500 hundred responses if need be for all i
> care just as long as they are predefined.

In the case of SAML, the recipient of a AuthZ Decision Assertion is supposed
to be a PEP who is enforcing access to some resources, not the end user who
is trying to access them. Presumably, the PEP has previously authenticated
itself to the satisfaction of the PDP. As I implied in my previous message,
if you are worried about leakage, you can use confidentiality (encryption).
This could even work if the assertion is passed via the user, assuming the
PEP knows the key and the user does not.

In the positive side, we do have requirements in SAML to be able to save
Assertions for non-repudiation purposes. In SAML v1 the Assertion will tell
you if the actions is allowed, but except for the object, the things in the
assertion and the inputs to the policy decision may not be the same. I was
hoping we could eventually fix this.

Hal


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


Powered by eList eXpress LLC