How-To: Dynamic Roles in WSO2 Identity Server

Modeling Dynamic Roles in XACML Policies

Introduction

Dynamic roles are roles that are assigned to users dynamically based upon the execution of a set of rules.

Though WSO2 Identity Server doesn’t advertise dynamic roles as a feature, it already has a powerful framework to author complex rules for authorization using XACML. In fact semantically we can map a XACML rule to a dynamic role. However, there are few gaps which prevent WSO2 Identity Server from supporting dynamic roles natively.

In this post I will be looking at how we can close these gaps by extending the WSO2 Identity Server, in order to support dynamic roles.

Requirements

In order to analyze the problem better and derive an optimum solution, let’s break down the requirement for “dynamic roles” into the following sub-requirements.

1. Ability to express complex rules
2. Ability to define a name for each complex rule which can corresponds to the dynamic role name
3. Ability to run through all the complex rules and evaluate them
4. Ability to evaluate the complex rules within the identity federation flow
5. Ability to insert the complex rule names of the rules which passed the evaluation, as a multi-valued claim into the identity federation response assertion for a user

Solution

The XACML Policy Administration Point (PAP) solves requirement 1 right away. We are able to define a XACML policy with multiple complex rules, each rule corresponding to a dynamic role. Also, in order to optimize the performance of the evaluation, make sure that the Target of this policy is defined in a uniquely distinguishable way so that, this and only this policy gets evaluated when fetching dynamic roles and at the same time this policy doesn’t get evaluated for other authorization evaluations. For example, the target of the policy could be something like the following with the policy combining algorithm set to urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable

<xacml3:Target>
    <xacml3:AnyOf>
        <xacml3:AllOf>
            <xacml3:Match MatchId=”urn:oasis:names:tc:xacml:1.0:function:string-equal”>
                <xacml3:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#String">dynamic-role-evaluation</xacml3:AttributeValue>
                <xacml3:AttributeDesignator Category=”urn:oasis:names:tc:xacml:3.0:attribute-category:action” AttributeId=”urn:oasis:names:tc:xacml:1.0:action:action-id” MustBePresent=”false” DataType="http://www.w3.org/2001/XMLSchema#string"/>
            </xacml3:Match>
        </xacml3:AllOf>
    </xacml3:AnyOf>
</xacml3:Target>

To implement requirement 2 we can make use of the AdviceExpressions. We can define an AdviceExpression for each rule with the Applies-To attribute with “permit” criteria. We can then define the AdviceId value with a special name that represents a dynamic role. E.g. AdviceId=“dynamic-role”. Finally we define the value of the AttributeValue element to be the dynamic role name we need.

The standard rule combining algorithms defined in XACML3 don’t allow you to run through all the rules defined in a policy and evaluate them, regardless of the results of the previously evaluated rules. However, in order to get the entire list of dynamic roles a user has, we should be able to do exactly that. Therefore in order to achieve requirement 3, we need to extend the XACML authorization framework by implementing a custom policy combining algorithm which evaluates every single rule in the policy, regardless of the results of the previously evaluated rules.

WSO2 Identity Server already supports evaluation of these complex rules over the HTTP network protocol using its XACML3 Rest/JSON API. What is missing though is a way to evaluate the same set of rules from within the identity federation flow, and transfer the resultant set of rule names that evaluated to true (which correspond to the dynamic roles of the user) to the service provider via the identity federation response assertion, instead of doing a separate HTTP call over the network which may add to the performance overhead.

In order to implement requirements 4 and 5 we will follow the below steps:

1. Define a new claim to represent dynamic roles in WSO2 Identity Server under the WSO2 dialect as “http://wso2.org/claims/dynamicRole”.
2. Implement a PostAuthenticationHandler extension in the identity federation framework, which invokes the XACML authorization engine, evaluates the XACML dynamic role policy, reads the advice elements which have an AdviceId value of “dynamic-role” returned in the XACML response, collects all the values defined in the AttributeValue element, and add those values as a multi-valued claim with claim URI “http://wso2.org/claims/dynamicRole” to the identity federation response assertion.
3. Now the service provider should be able to read the dynamic roles under “http://wso2.org/claims/dynamicRole” claim in the response assertion, understand the entitlements that a user gets with each dynamic role and be able to enforce them for the particular user.

References

[1] https://docs.wso2.com/display/IS580/Working+with+XACML

[2] http://xacmlinfo.org/2015/01/14/use-xacml-advice-elements-to-generate-detail-decisions/