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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

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

Subject: Re: [xacml-dev] Some queries regarding RBAC and XACML Profile fordelegation.

Muhammad Masoom Alam wrote:

>  Hi Erik ,
> I hope i am not borring you?

Hi Muhammad,

>  I have  some queries regarding the latest Profile for Delegation of
> The first question is, whether an Issuer can Constrain the delegation,
> or Delegation can only be constrained by Adminisration Policies. As
> stated in Profile that "In case <PolicyIssuer> element is present,
> then combinining Algorithms that can result in "Deny" SHALL NOT be
> used". ??

I don't understand this question. Sorry. :-(

> The 2nd question is that in the Administration Policy, uptil which
> level we can constrain delegation e.g. in the Administration Policy it
> can be specified that Carol can Delegate to Bob, by means of
> DelegateAttributeDesignator and LaterDelegateAttributeDesignator. But
> is this possible to further constrain that to whom Bob can delegate
> further??. If we specify a new administration policy take Bob as
> Delegatee, then what will be the value of the first policy in this
> regard. I mean, if Bob can delegate to Mallory (by an Administraton
> Policy), then there is no need to ask, that whether Bob is Authorized
> himself or not?? and on the other hand, if we can constrain multiple
> level of delegation, then it makes a long chain isnt so?

The <LaterDelegate> element of the request context is for this. The
<DelegateAttributeDesignator> is used to constrain that Carol can only
delegate to Bob. The <LaterDelegateAttributeDesignator> is used to
constrain to whom Bob can further delegate. You can use
<LaterDelegateAttributeDesignator> in a condition, thus constraining the
further delegation. The exact details of <LaterDelegate> are not
explored yet. It should be possible to refer to them using the higher
order functions of XACML, but I haven't tried out the details yet. Also,
the <LaterDelegate> elements should perhaps be ordered, to permit more
detailed conditions, if so desired. (BTW in the next draft,
LaterDelegate will change its name to IndirectDelegate.)

> Another issue is the integration of RBAC Profile for XACML with this
> delegation Profile.
>                    e.g. i have Role A, and Role B and Role B is super
> Role of Role A so how his inheritence relationship works in XACML profile
>                         --    There will a Role Policy Set (RPS) for
> every Role e.g. A & B
>                         --    There will be Permission Policy Set
> (PPS) for every Role too.
>                        --     Now, RPS will only contains Role
> Definition and will reference PPS e.g. As Role B is the super Role of
> Role A, there fore, RPS of  B will refer to its PPS and then PPS of B
> will refer to PPS of  Role A , to make this inheritence relationship
> in the XACML.

I don't understand your example (quoted below). The first policy set has
an unbalanced Policy element, and I am not sure how you intended it to
be. According to the RBAC profile there is no Policy element in the RPS,
so I assume that the target is really for the PolicySet. But in that
case, your policies will not match any request, since the top level
target has a delegate element and the nested policy set's target does
not have it.

Also, I am not sure what you mean when you say "integrate" with the RBAC
profile. "Integration" could refer to a number of delegation related
features and RBAC.

One feature of integration would be that if someone has been delegated
the right to create access permissions, then he should be able to
organize those permissions with the RBAC model. This should work. He
will simply be the issuer of the RPSs, and the access requests that are
permitted by his RBAC policies will be authorized by the administrative
policies as usual.

Another level of integration with delegation would be to look at how the
management of the RBAC permissions could be delegated. RBAC has three
operations: user-role assignment, permission-role assignment and
role-role assignment. For each of these, we can imagine that the right
to perform the opertation could be delegated and that different people
could be doing each of the operations.

Since user-role assignment is done by means of an attribute assignment,
it really falls outside the scope of XACML. I have worked on this issue
and I have ideas for how to do it, but I haven't tried them out yet. In
my opinion, delegation of attribute assignment is important in a
delegated access control system, and might be something that XACML could
support in the future, but this is nothing that has to my knowledge ever
been discussed in the XACML TC.

When it comes to role-role and role-permission assignment, the
delegation profile doesn't go very well with RBAC. The problem lies in
that RBAC is fundamentally based around the role concept in how it
constrains administrative operations. The delegation profile is on the
other hand based on the source of authority for a resource. The RBAC
administrative models ask "will this operation violate the desired
properties of the role hiearchy?", while the XACML delegation profile
asks "has this issuer been authorized to allow this access?".

These views are fundamentally different and cannot be easily reconciled.
For instance, in RBAC the act to add a resource to a role must be
perfomed by the a role administrator with autority over the _role_,
while in the delegation profile it has to be done by an administrator
with authority over the _resource_. I find the latter approach more
correct, since in a distributed and decentralized system we cannot
assume that role administrators are the same people as the resource owners.

This also means that in the model on which the delegation draft is
based, it is possible for someone to add permissions to roles created by
other people, which is not possible in classic administrative RBAC. This
might first seem a bit weird, but when you think about it, it's really
how things are in a distributed system by nature. If I say that you have
"attribute X", then I cannot really prevent other people from saying
that "if you have attribute X, then you can use my resource". (At least
as long as the attribute X is publicly available. I could try to keep it

A summary of this long answer would be that: someone writing access
policies in a delegated environment can do so be means of the RBAC
profile, but the administrative operations of ARBAC don't really map to
the delegation profile. Though I haven't really worked on this yet.

Personally I think that the ARBAC is not the right solution since it
assumes that the role owners have authority over all resources too.
Also, the ARBAC role hierarchy really mixes two kinds of hierarchies:
the is-a relation and the administrative authority. They should be
separate. RBAC02 is moving in this direction by starting to separate the
two. In the delegation profile they are already separate: the
administrative hierarchy is implemented in the delegation hierarchy and
the is-a hierarchy is implementd with the nested policy sets.

Anyway, I am interested in this, so keep us posted.

Regards, Erik

> Now considering the same for Delegation Profile
> i think so
> we can have RPS like this
> <PolicySet>
> <Policy PolicyId="RPS_Role_B"
> RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">
> <Target>
> <AnySubject/>
> <AnyResource/>
> <AnyActioin/>
> <Delegates>
> <Delegate>
> <DelegateMatch
> MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
>        <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string";>RoleB</AttributeValue>
> <DelegateAttributeDesignator
> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
> DataType="http://www.w3.org/2001/XMLSchema#string"/>
> </DelegateMatch>
> </Delegate>
> </Delegates>
> </Target>
> <PolicySetIDreference> PPS_OF_RoleB </PolicySetIDReference>
> </PolicySet>
> and then PPS of Role B will contain the Definition of actual
> permission with a reference to PPS of role A since it is the super
> Role. make sence ??
> <PolicySet>
> <Policy PolicyId="Policy PPS_OF_RoleB"
> RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">
> <Target>
> <Subjects>
> <Subject>
> <SubjectMatch
> MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
> <AttributeValueDataType=http://www.w3.org/2001/XMLSchema#string
>> employee</AttributeValue>
> <SubjectAttributeDesignator
> AttributeId="group"
> DataType="http://www.w3.org/2001/XMLSchema#string"/>
> </SubjectMatch>
> </Subject>
> </Subjects>
> <Resources>
> <Resource>
> <ResourceMatch
> MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
> <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string";>printer</AttributeValue>
> <ResourceAttributeDesignator
> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
> DataType="http://www.w3.org/2001/XMLSchema#string"/>
> </ResourceMatch>
> </Resource>
> </Resources>
> <Actions> <Action>
> <ActionMatch
> MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
> <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string";>print</AttributeValue>
> <ActionAttributeDesignator
> AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
> DataType="http://www.w3.org/2001/XMLSchema#string"/>
> </ActionMatch>
> </Action>
> </Actions>
> </Target>
> <Rule RuleId="Rule1" Effect="Permit">
> <Target>
> <Subjects><AnySubject/></Subjects>
> <Resources><AnyResource/></Resources>
> <Actions><AnyAction/></Actions>
> </Target>
> </Rule>
> <PolicySetIdReference> PPS_OF_ROle_A </PolicySetIdReference>
> </PolicySet>
> The thing is that RPS will only contains the Delegate element and will
> reference the PPS where as PPS will contains permission and
> additionally a referece to another PPS for inheritence relationship.
> I hope i was able to convey my idea.
> with Best regards
> Muhammad.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-dev-help@lists.oasis-open.org

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