[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
- From: Frank Siebenlist <franks@mcs.anl.gov>
- To: Tim Moses <tim.moses@entrust.com>, Anne Anderson <Anne.Anderson@Sun.com>,Carlisle Adams <carlisle.adams@entrust.com>
- Date: Wed, 23 Apr 2003 10:20:18 -0700
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
- From: Frank Siebenlist <franks@mcs.anl.gov>
- To: Tim Moses <tim.moses@entrust.com>, Anne Anderson <Anne.Anderson@Sun.com>,Carlisle Adams <carlisle.adams@entrust.com>
- 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
- From: Frank Siebenlist <franks@mcs.anl.gov>
- To: Anne.Anderson@sun.com
- Date: Wed, 23 Apr 2003 20:52:54 -0700
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
- From: Frank Siebenlist <franks@mcs.anl.gov>
- To: Tim Moses <tim.moses@entrust.com>, Anne Anderson <Anne.Anderson@Sun.com>,Carlisle Adams <carlisle.adams@entrust.com>
- Date: Thu, 24 Apr 2003 10:18:30 -0700
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
- From: Anne Anderson <Anne.Anderson@Sun.com>
- To: Frank Siebenlist <franks@mcs.anl.gov>
- Date: Thu, 24 Apr 2003 13:47:47 -0400
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]