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




Oleg Gryb wrote:
> David,
> 
> It's very interesting and useful information. I'm not familiar with this spec, but will definitely check it out. Two qucik qs about this:
> 
> 1. Are there any implementations for this spec? Please provide references if you have any.

www.openpermis.org (java source) and
sec.cs.kent.ac.uk/permis (binaries)
implements all three specs
there are various other implementations of the XACML profile and a SAML 
AA implementation from INFN in Italy.

> 2. Does the spec cover attributes that are stored in a relational DB?

Not directly, but if you put the SAML front end to it, say using 
OpenSAMLv2, then yes.

regards

David

> 
> Thanks,
> Oleg.
> 
> --- On Mon, 11/3/08, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
> 
>> From: David Chadwick <d.w.chadwick@kent.ac.uk>
>> Subject: Re: [xacml-users] Help on ResourceConent <-- On XACML Architecture
>> To: oleg@gryb.info
>> Cc: "Balaji Kannadassan" <balajika@nortel.com>, d95776@yahoo.com, xacml-users@lists.oasis-open.org
>> Date: Monday, November 3, 2008, 2:38 PM
>> 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
>>
>> *****************************************************************
> 
> 
>       
> 
> ---------------------------------------------------------------------
> 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]