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] Help on ResourceConent <-- On XACML Architecture


Dear Balaji and all

the problem of authz credential resolution is something the OpenGrid 
Forum has been working on for several years. We now have a set of 
specifications which show how standard solutions can be used to collect 
and validate user authz credentials and extract the relevant attributes 
from them, which can then be given to the XACML PDP. In particular SAML 
attribute assertions can be used as authz credentials (but so too can 
X.509 ACs, X.509 PKCs, Kerberos tokens or anything else that assert that 
a particular user has a particular attribute).

The OGF specifications are publicly available. You can pick up the 
latest specs from here

http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-authz/docman.root.authz_service

The ones you will want are

doc15253: Use of WS-TRUST and SAML to access a CVS   06/13/2008  	

doc15173: Use of SAML to retrieve Authorization Credentials 04/07/2008 	

doc15171: Functional Components of Grid SP Authz Service Middleware 	 
04/06/2008 	

doc15169: Use of XACML Request Context to Obtain an Authorisation Decision


Open source implementations of the specifications also exist.

regards

David

Oleg Gryb wrote:
> Balaji,
> 
> Since you've mentioned "architecture" you're probably trying to create a XACML-based authz architecture for your client. If this is the case you'll probably find my experience interesting.
> 
> I think, the major problem that a security architect needs to solve in the case of XACML-based solution is attribute resolution mechanism. We had a discussion on this forum in the past and had some disagreements, but it looks like all arguing parties had agreed that XACML-based authz solution will have a very limited value if it doesn't have dynamic attribute resolution mechanism in place. I think, the other thing that we agreed on was that the latter mechanism is poorly defined in XACML 2.0.
> 
> Practical consequences of that could be that vendor's implementations of attribute resolution could be (and they actually are for vendors that I've evaluated) absolutely incompatible that could lead to vendor "lock in situation", which any architect should try to avoid.
> 
> The best solution that I found was not to rely on context handler that can be called from PDP, but resolve all attributes before request hits PDP. Sequence diagram at http://gryb.info/images/attrs.jpg provides more details.
> 
> I think this approach could be used in scenario that has been described by Hao. In his case a client would need to submit: account ID and subject ID with roles in initial request. Attribute resolver, presented at the diagram, would use the account ID attribute to create yet another attribute - "AccountHasBeenReviewedByManager". The enhanced request will be sent to PDP that will not care about attribute resolution any more. I think the behavior of PDP itself (without context handling) is defined fairly well in XACML 2.0. That definition plus conformance tests will give you a very high degree of confidence that PDP engine vendor's implementations (without context handling) are compatible.
> 
> Hope it helps,
> Oleg.
> 
> 
> 
> --- On Mon, 11/3/08, Balaji Kannadassan <balajika@nortel.com> wrote:
> 
>> From: Balaji Kannadassan <balajika@nortel.com>
>> Subject: RE: [xacml-users] Help on ResourceConent!
>> To: "Roland Illig" <roland.illig@gmx.de>
>> Cc: xacml-users@lists.oasis-open.org
>> Date: Monday, November 3, 2008, 3:53 AM
>> Hi Roland!
>>
>>    It wasn't specified anywhere since you said in
>> standard xml its not
>> implemented assume its 1.0v is standard. Sorry if I have
>> confused you,
>> So on whole it's the difference between the usage of
>> AttributeSelector
>> and AttributeDesignator. So if I am using Attribute
>> Designator hyperlink
>> or location would suffice rt ?.  Since in the example of
>> DoB they use
>> Attribute Selector prefetched details are placed.
>>
>> Other Experts >> Please do help me in my
>> understanding of the request
>> flow on the XACML Policy architecture ?. 
>> 			Is my understanding rt as stated below  on
>> PDP/PEP/PAP/PIP ?
>>
>> Thanks
>> Balaji Kamal Kannadassan
>>
>> -----Original Message-----
>> From: Roland Illig [mailto:roland.illig@gmx.de] 
>> Sent: Monday, November 03, 2008 2:08 PM
>> To: Kannadassan, Balaji (AMR:8826)
>> Cc: xacml-users@lists.oasis-open.org
>> Subject: Re: [xacml-users] Help on ResourceConent!
>>
>> Balaji Kannadassan schrieb:
>>> Hi Roland!
>>>
>>>     As you have said said that only embedded details
>> can be read by 
>>> 1.0v, had a doubt on how are these values prefetched,
>> so is it that
>>
>> I meant: the <AttributeSelector> can only search
>> inside the <Request>
>> XML that is provided to the PDP. I know that the
>> <*AttributeDesignator>s
>> can get arbitrary information.
>>
>>>         a) PEP send that the detail of the doctor who
>> wanted to read 
>>> bart's DOB
>>>         b) Context Handler will prefetch DOB details
>> via PIP and place
>>
>>> it in the Resource Content and push it across to PDP.
>>>         c) Now PDP has all these prefetched detail
>>>         d) PDP takes a decision on what to with
>> operation the person 
>>> wants to do via PAP
>> I don't know that part of XACML very well, so I cannot
>> say definitely
>> how it works.
>>
>>> So in 1.0 PDP didn't had the provision to delve
>> into just the 
>>> hyperlink for the record provided. In 2.0 there is an
>> enhancement for 
>>> the same to get the details from the hyperlink.
>> Oh, I didn't know that. Where is it defined?
>>
>> Roland
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> xacml-users-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail:
>> xacml-users-help@lists.oasis-open.org
> 
> 
>       
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************


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