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

[Oleg Gryb <oleg_gryb@yahoo.com>]

I think if you you use it in environment match and the attribute doesn't match then you'll get "Not Applicable" from PDP, but as I understand you want to have "Deny" in this case.

That's why I think it will be better to have the boolean-equal function implemented in a rule.

In regards using or not using variables, I'm not sure why you need variables here... The simple condition that will do the work is below:

<Condition>
  <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:boolean-equal">
    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#boolean";>true</AttributeValue>
    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:boolean-one-and-only">
      <EnvironmentAttributeDesignator AttributeId="account:ReviewedByManager" MustBePresent="true" Issuer="hoa" DataType="http://www.w3.org/2001/XMLSchema#boolean"/>
    </Apply>
  </Apply>
</Condition>

(created with XACML-Studio :)


--- On Mon, 11/3/08, hao chen <d95776@yahoo.com> wrote:

> From: hao chen <d95776@yahoo.com>
> Subject: RE: [xacml-users] Help on ResourceConent <-- On XACML Architecture
> To: "Balaji Kannadassan" <balajika@nortel.com>, oleg@gryb.info
> Cc: xacml-users@lists.oasis-open.org
> Date: Monday, November 3, 2008, 3:10 PM
> Hi Oleg,
> 
> I agree with you. But I still have questions on where is
> the best place to enforce the condition since we will treat
> AccountHasBeenReviewedByManager as a condition attribute. We
> can enforce it at environment match, rule conditon, and rule
> condition with variable reference. I would like to know your
> recommendations on how to enforce the condition.
> 
> Thanks a lot!
> 
> hao
> 
> Best Regard
> 
> 
> --- On Mon, 11/3/08, Oleg Gryb <oleg_gryb@yahoo.com>
> wrote:
> 
> > From: Oleg Gryb <oleg_gryb@yahoo.com>
> > Subject: RE: [xacml-users] Help on ResourceConent
> <-- On XACML Architecture
> > To: "Balaji Kannadassan"
> <balajika@nortel.com>, d95776@yahoo.com
> > Cc: xacml-users@lists.oasis-open.org
> > Date: Monday, November 3, 2008, 12:12 PM
> > 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