Re: [xacml-users] Help on ResourceConent <-- On XACML Architecture

[Oleg Gryb <oleg_gryb@yahoo.com>]

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.
2. Does the spec cover attributes that are stored in a relational DB?

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
> 
> *****************************************************************