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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: (old) XACML questions and feature requests

During the conference call this morning, I alluded to some emails that I sent to 
a subset of the xacml tc in April - Please find those attached.

This was right after our group took a close look at xacml for potential future 
inclusion in our globus toolkit, and before deciding to take a more active role 
to ensure that our requirements would be addressed in the next incarnations of 
xacml. In retrospect, these emails should probably have been sent to the 
tc-mailing list...

Some of the questions/requirements are based on misunderstandings, some are 
already addressed in Anne's xacml 2.0 work item list, and some are not. I'll 
take an other look.

Enjoy, Frank.

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory


Hi XACML experts,

We're trying to render some of our use cases on top of xacml, and I'm running into some problems of howto.

I wasn't sure if the xacml mailing list is appropriate for these novice questions, so I'm bothering you directly. Hope you don't 
mind, and maybe we should take it to a mailing list if appropriate.

Our application is the following:

We have an experimental implementation of the Community Authorization Service (CAS), which addresses some of the issues we see in 
distributed environments where the resource owners do not have (and do not want) access control policy for the individual requesters 
coming from a foreign domain.
The idea is that these requesters will have a CAS in their domain "A", which they can ask for authorization assertions that can be 
used on resources of domain "B". The access rights issued by that CAS should be a subset of the access rights that the CAS-identity 
itself has on the resource in domain "B".

The access control policy in domain B will know only the CAS-identity of domain A, give it access right to some of its resources, 
and allow if to delegate its rights to other identities.
CAS will manage the access control policy applicable to the resources in domain B for the identities in domain A.

Our current CAS issues rights to requesters in the form of rules, e.g. "Frank has the right to read any file from directory 
acme.com/docs/".

If the requester from A presents a request to the resource in domain B to read file acme.com/doc/abc.txt together with the 
CAS-issued assertion, the resource will validate the identities of both requester throught the message and CAS through the signed 
assertion. It will then check whether the CAS identity is allowed to perform the requested action according to its own policy, and 
if so, it will evaluate the rule in the assertion as it applies to the request. If the latter also yield a positive permission, the 
request will be honored.

Currently we use our own language to express these assertions, and we have our own evaluators on the resource. We would like to see 
how we could implement this in a xacml-ruled world.

My first idea was to have CAS issue the collection of xacml-policy-sets/policies/rules as a signed authorization assertion, which 
would apply to the target, i.e. the requester's subject, with the resource and action requested.

At the resource's PEP, the first <request> to the context handler should include the CAS's subject with the detailed 
resource/action, which gets evaluated by the PDP according to the locally administered policy.

The second <request> is more complicated, because now I have these CAS-policy/rules, that I would like to have evaluated by the 
resource's PDP. It almost feels like I should be able to present these rules as an subject attribute value, and that I need some 
"eval" function that makes the PDP evaluate the presented policy/rules instead of its own local ones.

As a possible alternative, we could have the CAS issue the <result> as it is evaluated by its own pdp. This could also be seen as an 
authorization assertion. However, this would probably only work if there is an absolute match of the target in this assertion and 
the target as it is requested on the resource. It may not work if you ask the CAS to read permission in a directory, and then ask 
the resource to read a file in that directory - this requires an additional matching of resource details. It also wouldn't work if 
the CAS policy allows you read access only from 9am-5pm, as that rule has to be evaluated at the resource.

An other option would be to feed the CAS-policies in through the administrative channel, i.e. the resource's PAP, but that doesn't 
sound very "portable" and feels somewhat of a kludge.

Anyway, I'm confident that you could direct us to the proper solution ... Please...

Thanks for your help.
Regards, Frank.

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory




Some more beginner's questions:

1) How to specify policy rules for the requestor's authorization policy?
The spec seems to be somewhat silent on the requestor's side authorization decision to see whether the requestor's policy allows the 
service provider to service the request.
There are subject categories defined for access-subject, recipient-subject, and intermediary-subject. I guess we could use the 
recipient-subject for the service provider's subject, although I have the feeling that that was not its intension.
Should we maybe define a "provider-subject" to more clearly distinguish the context where the access control decision is made?

2) How to use xacml policy to bootstrap the trust?
In a xacml-ruled world, all policy should be defined in policy-sets/policies/rules, and PDPs should be used everywhere for all 
authorization decisions...
If a resource's PEP uses an external access control decision service for its PDP, then we need to bootstrap that trust. The PEP must 
have a locallly stored policy with a local PDP that is able to evaluate whether the subject associated with the PDP service is 
allowed to decide on all relevant policy decisions for that PEP.
It's not clear how you specify that rule. How do you express a rule that a subject is allowed to serve as a PDP for a certain set of 
resources and actions? It seems to be implicit in a policy/rule, but I do not see how I can associate the policy authority's subject 
with it...

3) How to use xacml to delegate trust?
This is very much related and maybe identical to 2), but the use case is different.
In our Grid environment, we have resources with associated identities that are created on the fly. There is therefor no existing, 
explicit policy for those entities.
The way we deal with it is that there is one identity that is kind of the trust anchor for these newly created beings. This 
so-called Grid Resource Identity Manager (GRIM) issues dynamically identity and authorization assertions that are used both by the 
newly created services as well as the requestors to decide whether they are allowed to talk to each other.
We therefor need to define a policy for the requestor that will "trust" this GRIM identity to function as a PDP for all the 
authorization decisions related to access to the GRIM managed resources.

Or as an alternative, the GRIM could send the relevant policies/rules to the requestor such that the requestor's PDP itself can 
evaluate the rules. This is very much like the use case in my previous email, and that's actually how we have implemented it now.

---

I hope my questions relate the fact that we are very seriously looking at XACML, and would love to see how we can deploy it in our 
current applications.

Regards, Frank.

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory




Hi Anne,

Anne Anderson - Sun Microsystems wrote:
> ...
> I sent Tim Moses an example of a client policy and a server policy yesterday.
> I need him to check them over, but I think once we get the example worked
> out, it will help answer your first question.  Tim said he would probably 
> be able to look at it at the end of this week.

Good to hear that you're addressing one piece of the puzzle already
(and that you're keeping Tim busy ;-)

If you want we could give you a detailed example from our world, and try to figure out together what attributes, rules and condition 
we need defined. I've come to the conclusion that we need such a worked out detailed example to see how far we get with xacml, where 
the possible gaps are, and the possible solutions. We're willing to put time such an effort.


Regards, Frank.


> "Frank Siebenlist" <franks@mcs.anl.gov> wrote:
> 
>>Date: Wed, 23 Apr 2003 14:58:18 -0700
>>Some more beginner's questions:
>>
>>1) How to specify policy rules for the requestor's authorization policy?
>>The spec seems to be somewhat silent on the requestor's side authorization
>>decision to see whether the requestor's policy allows the 
>>service provider to service the request.
>>There are subject categories defined for access-subject, recipient-subject, and
>>intermediary-subject. I guess we could use the 
>>recipient-subject for the service provider's subject, although I have the
>>feeling that that was not its intension.
>>Should we maybe define a "provider-subject" to more clearly distinguish the
>>context where the access control decision is made?
>>
>>2) How to use xacml policy to bootstrap the trust?
>>In a xacml-ruled world, all policy should be defined in
>>policy-sets/policies/rules, and PDPs should be used everywhere for all 
>>authorization decisions...
>>If a resource's PEP uses an external access control decision service for its
>>PDP, then we need to bootstrap that trust. The PEP must 
>>have a locallly stored policy with a local PDP that is able to evaluate whether
>>the subject associated with the PDP service is 
>>allowed to decide on all relevant policy decisions for that PEP.
>>It's not clear how you specify that rule. How do you express a rule that a
>>subject is allowed to serve as a PDP for a certain set of 
>>resources and actions? It seems to be implicit in a policy/rule, but I do not
>>see how I can associate the policy authority's subject 
>>with it...
>>
>>3) How to use xacml to delegate trust?
>>This is very much related and maybe identical to 2), but the use case is
>>different.
>>In our Grid environment, we have resources with associated identities that are
>>created on the fly. There is therefor no existing, 
>>explicit policy for those entities.
>>The way we deal with it is that there is one identity that is kind of the trust
>>anchor for these newly created beings. This 
>>so-called Grid Resource Identity Manager (GRIM) issues dynamically identity and
>>authorization assertions that are used both by the 
>>newly created services as well as the requestors to decide whether they are
>>allowed to talk to each other.
>>We therefor need to define a policy for the requestor that will "trust" this
>>GRIM identity to function as a PDP for all the 
>>authorization decisions related to access to the GRIM managed resources.
>>
>>Or as an alternative, the GRIM could send the relevant policies/rules to the
>>requestor such that the requestor's PDP itself can 
>>evaluate the rules. This is very much like the use case in my previous email,
>>and that's actually how we have implemented it now.
>>
>>---
>>
>>I hope my questions relate the fact that we are very seriously looking at XACML,
>>and would love to see how we can deploy it in our 
>>current applications.
>>
>>Regards, Frank.
>>
>>-- 
>>Frank Siebenlist              franks@mcs.anl.gov
>>The Globus Project - Argonne National Laboratory
>>
> 
> 
> Anne
> ------
> Anne Anderson          Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> Burlington, MA         781-442-0928
> 

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory




A few more puzzle pieces that I can't find. They might be missing or I haven't 
looked well enough:

4) XACML wsdl/porttype definition for <Request>/<Response> exchange
If we would use a centralized "authorization" service, it seems most natural to 
abstract the decision request and response messages between the context handler 
and the PDP into a wsdl/porttype definition.

This context handler seems to be doing a lot of work to get all the required 
info from the native formats into this canonicalized representation.
I guess that the PIP could be an XKMS service?

5) Need new SAML profile for XACML attribute assertions
If application still have a choice, then it may make sense to make the 
conversion to the xacml representation of attributes at soon as possible, and 
they may even start out with that.
 From an application point of view it makes sense to translate all the receieved 
assertions in a standard canonical representation, even outside of XACML, such 
that it becomes easier to reason about them.
There seems to be a mismatch betweeen the current SAML assertions and the XACML 
attributes. It would be best to define a new SAML profile such that attribute 
assertions can use the xacml representation.

6) Need SAML profile for authorization/policy assertions
As I mentioned in my first email, case "0)", we have a need to communicate 
authorization assertions, and it may make sense to use the xacml 
policy-set/policy/rule elements as the format. We still need to wrap them up in 
some signed envelope in a standardized manner, and it could make sense to define 
another SAML profile for that as it doesn't seem to fit well within the current 
SAML authorization assertion.

7) Primitive to express policy to reveal missing attributes?
Quoting from the spec:
<quote>
"urn:oasis:names:tc:xacml:1.0:status:missing-attribute 2805
A PDP MAY choose not to return any <StatusDetail> information or MAY choose to 
return a 2806 <StatusDetail> element containing one or more 
xacml-context:Attribute> elements. If 2807 the PDP includes <AttributeValue> 
elements in the <Attribute> element, then this indicates 2808
the acceptable values for that attribute. If no <AttributeValue> elements are 
included, then 2809 this indicates the names of attributes that the PDP failed 
to resolve during its evaluation. The list 2810 of attributes may be partial or 
complete. There is no guarantee by the PDP that supplying the 2811
missing values or attributes will be sufficient to satisfy the policy.
</quote>
I find the returning of missing attributes very intriguiging. It still is 
unclear to me how we're going to find out what attributes we need from what 
authority such that we may be able to satisfy the the policy that allows access. 
If we could get that information by trying, or querying the policy service, that 
could be a working solution.
As mentioned, the returning of the missing attribute info is sensitive 
information and should itself be subject to policy. What I can't figure out, 
however, is what rule primitives I could use to express that policy...

---

Enough for now...
Regards, Frank.

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory




On 24 April, Frank Siebenlist writes: XACML Howto? (3)
 > 6) Need SAML profile for authorization/policy assertions
 > As I mentioned in my first email, case "0)", we have a need to communicate 
 > authorization assertions, and it may make sense to use the xacml 
 > policy-set/policy/rule elements as the format. We still need to wrap them up in 
 > some signed envelope in a standardized manner, and it could make sense to define 
 > another SAML profile for that as it doesn't seem to fit well within the current 
 > SAML authorization assertion.

The draft XACML XML DSig Profile
(http://lists.oasis-open.org/archives/xacml/200303/msg00063.html)
contains an example of an XACML Policy enclosed in a SAML
Assertion.  See Section 4.4.  It is very straightforward.  I used
the issuer of the Assertion (policy) as the Subject.

 > 7) Primitive to express policy to reveal missing attributes?
 > Quoting from the spec:
 > <quote>
 > "urn:oasis:names:tc:xacml:1.0:status:missing-attribute 2805
 > A PDP MAY choose not to return any <StatusDetail> information or MAY choose to 
 > return a 2806 <StatusDetail> element containing one or more 
 > xacml-context:Attribute> elements. If 2807 the PDP includes <AttributeValue> 
 > elements in the <Attribute> element, then this indicates 2808
 > the acceptable values for that attribute. If no <AttributeValue> elements are 
 > included, then 2809 this indicates the names of attributes that the PDP failed 
 > to resolve during its evaluation. The list 2810 of attributes may be partial or 
 > complete. There is no guarantee by the PDP that supplying the 2811
 > missing values or attributes will be sufficient to satisfy the policy.
 > </quote>
 > I find the returning of missing attributes very intriguiging. It still is 
 > unclear to me how we're going to find out what attributes we need from what 
 > authority such that we may be able to satisfy the the policy that allows access. 
 > If we could get that information by trying, or querying the policy service, that 
 > could be a working solution.
 > As mentioned, the returning of the missing attribute info is sensitive 
 > information and should itself be subject to policy. What I can't figure out, 
 > however, is what rule primitives I could use to express that policy...


I think this can be a standard access control policy:
  PDP doing the returning = access-subject Subject
  PEP receiving the returned attributes = recipient-subject Subject
  AttributeId to be returned = Resource
  "Disclose to PEP" = Action

Sample rule:

 Pseudo-English:

  if  access-subject subject-id is PDP L
  and recipient-subject subject-id is PEP A, PEP B, or PEP C
  and resource-id is AttributeId X, or Y
  and action-id is "Disclose to PEP"

 Pseudo-XACML:

  <Rule Effect="Permit">
    <Target>
      <Subjects>
        <Subject SubjectCategory="recipient-subject">
           <SubjectMatch>
              subject-id = PEP A
           </SubjectMatch>
        </Subject>
        <Subject SubjectCategory="recipient-subject">
           <SubjectMatch>
              subject-id = PEP B
           </SubjectMatch>
        </Subject>
        <Subject SubjectCategory="recipient-subject">
           <SubjectMatch>
              subject-id = PEP C
           </SubjectMatch>
        </Subject>
      </Subjects>
      <Resources>
        <Resource>
          <ResourceMatch>
             resource-id = AttributeId X
          </ResourceMatch>
        </Resource>
        <Resource>
          <ResourceMatch>
             resource-id = AttributeId Y
          </ResourceMatch>
        </Resource>
      </Resources>
      <Actions>
        <Action>
          <ActionMatch>
            action-id = "Disclose to PEP"
          </ActionMatch>
        </Action>
      </Actions>
    </Target>
    <Condition FunctionId="is-in">
        <AttributeValue>L</AttributeValue>
        <SubjectAttributeDesignator SubjectCategory="access-subject
            AttributeId="subject-id"/>
    </Condition>
  </Rule>
  
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

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