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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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

Subject: RE: [xacml-users] Third-party Pre-Fetch of authorization decision


> You're right that this isn't covered explicitly in the spec, 
> but it's definitely a supportable case, and pretty easy to 
> do. The reason it's not covered in the XACML spec is because 
> this is more a function of the authorization system built 
> around XACML, and at this level (also where attributes are 
> managed, PEPs are administered, policies are created, etc) 
> XACML is non-specific so you can work witch whichever systems 
> you have/need.

Well, given that XACML does describe in substantial detail
the message flow of the pull process for obtaining decisions,
I would think that some discussion about an example push 
process would be useful in showing the broadness of the 
specification without normatively specifying that as the
only way to do push.  Just my $.02.

> My suggestion for the easiest way to attack your problem is 
> with SAML. It's designed for sending requests, getting signed 
> responses, and even correlating requests and responses. It 
> should be very easy to implement support for this, and as 
> more SAML/XACML implementations show up, you should be able 
> to take advantage of them.

Yeah, I had anticipated using SAML as part of this process,
at least at the level of the assertion protecting the decision.

> Note that the challenge here (that I'm sure you've already thought
> of) besides signing the messages is expiration. XACML doesn't 
> talk about when attributes expire, so it's somewhat hard to 
> be precise about how long a decision stays valid. It's up to 
> your system to track these dependencies.

SAML does provide the out-of-the-box conditions allowing the 
issuer to restrict the consumption timeframe and they have a 
model for the authentication statement providing a timeframe
for the derived session initiated by the authentication (which
could be a model for the decision side, but as you pointed out,
this isn't called out in either the SAML profile of XACML
nor as a general statement attribute.


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