How-To: Access Requests & Approvals in WSO2 Identity Server

Coarse-grained Authorization Fused with Approval Workflows

Introduction

“Access requests” and “access approvals” are key features in most access governance solutions. Access requests allow access to resources to be requested for users. Access requests can either be made by administrators on behalf of users or they can be made by the users themselves. The second type of access requests are known as “self-service access requests”. Access approvals refer to the subsequent process of granting access to the requested resources. Access approvals can either be automated or require manual administrative action.

Though WSO2 Identity Server doesn’t advertise “access requests” and “access approvals” as first-class features, it possesses a powerful authorization framework that can do coarse-grained authorization for applications and a very extensible workflow management capability.

In this post, I will be discussing how WSO2 Identity Server can support access requests and access approvals for applications by fusing the above two powerful capabilities it possesses.

Requirements

The problem of “access requests” and “access approvals” can be broken down into the following requirements:

1. Ability to enforce a coarse-grained authorization policy for a given application, that prevents all users from getting access by default.
2. Ability to express a coarse-grained authorization policy for a given application, that selectively allows users to access the application based on a condition.
3. Ability to define the condition in the authorization policy based on a variable.
4. Ability to modify the value of the variable.
5. Engage an approval workflow for the modification of the variable value.

Solution

Requirements 1–3 can be solved using a coarse-grained authorization policy in XACML 3.0, that provides role-based authorization for log-in [1].

Sample XACML 3.0 Policy

The following policy enforces coarse-grained authorization for the “Pickup-Manager” [1] application based on “pickup-manager-log-in” role.

<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="pickup_manager_coarse_grained_authz_policy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
   <Description>This is a coarse-grained authorization policy for Pickup-Manager. This policy authorizes users in pickup-manager-log-in role to log-in to Pickup-Manager. All other users are denied log-in to Pickup-Manager</Description>
   <Target>
      <AnyOf>
         <AllOf>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Pickup-Manager</AttributeValue>
               <AttributeDesignator AttributeId="http://wso2.org/identity/sp/sp-name" Category="http://wso2.org/identity/sp" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"></AttributeDesignator>
            </Match>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">authenticate</AttributeValue>
               <AttributeDesignator AttributeId="http://wso2.org/identity/identity-action/action-name" Category="http://wso2.org/identity/identity-action" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"></AttributeDesignator>
            </Match>
         </AllOf>
      </AnyOf>
   </Target>
   <Rule Effect="Permit" RuleId="permit_by_roles">
      <Condition>
         <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:or">
            <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">pickup-manager-log-in</AttributeValue>
               <AttributeDesignator AttributeId="http://wso2.org/claims/role" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
            </Apply>
         </Apply>
      </Condition>
   </Rule>
   <Rule Effect="Deny" RuleId="deny_others"></Rule>
</Policy>

When the above policy is enforced, if you try to log-in using an account that is not in the “pickup-manager-log-in” role, you would receive the following an authorization failure.

Figure 1: Authorization failure for user “johann” who is not in the “pickup-manager-log-in” role

If the variable is chosen as role, then requirement 4 can be easily catered either via management console or SCIM 2.0 Groups endpoint.

Requirement 5 can be solved by engaging a multi-level/multi-option approval workflow for the user role assignment operation [2,3,4].

Figure 2: Creating an approval workflow for “Pickup-Manager” log-in

Figure 3: Defining a single step approval workflow with “pickup-admin” role as approver

Figure 4: Selecting the BPS profile to deploy and run the approval workflow

Figure 5: Engaging the “pickup-manger-log-in” workflow to “Update Roles of User” operation

Figure 6: Engaging the “pickup-manger-log-in” workflow to “Update Users of Role” operation

Figure 7: The administrator initiating an access request for user “johann” to access “pickup-manger” application

Figure 8: “Pickup-Manager” access for user “johann” is not granted right away

Figure 9: Alternative way of initiating an access request for user “johann” to access “pickup-manager” application

Figure 8: “Pickup-Manager” access for user “johann” is not granted right away

Figure 11: Authorization failure for user “johann” who is not in the “pickup-manager-log-in” role yet

Figure 12: A workflow instance created to approve assignment of user “johann” to “pickup-manager-log-in” role

Figure 13: An approval task to assign user “johann” to “pickup-manager-log-in” role is reserved for user “prabath” as he is in “pickup-admin” role

Figure 14: User “prabath” approves the assignment of user “johann” to “pickup-manager-log-in” role

Figure 15: The approval task to assign user “johann” to “pickup-manager-log-in” role is completed by user “prabath”

Figure 16: The workflow instance to approve assignment of user “johann” to “pickup-manager-log-in” role has been removed

Figure 17: User “johann” is in “pickup-manager-log-in” role now

Figure 18: “pickup-manager-log-in” is contains user “johann” in its list

Figure 19: User “johann” is able to successfully pass the authentication steps and provide consent to “Pickup-Manager“ application

Figure 20: User “johann” is able to successfully log-in to the “Pickup-Manager“ application

The level of access approval capability that I’ve described here, is what you would get out-of-the-box in WSO2 Identity Server as of the latest version — 5.10.0. However, if you are interested in getting further customization capabilities for the workflow, then you could explore the option of integration WSO2 Identity Server with an externally deployed WSO2 Business Process Server (BPS) [5].

References

[1] https://is.docs.wso2.com/en/5.10.0/learn/configuring-oauth2-openid-connect-single-sign-on/

[2] https://is.docs.wso2.com/en/5.10.0/learn/deploying-the-sample-app/#deploying-the-pickup-manager-webapp

[3] https://is.docs.wso2.com/en/5.10.0/learn/configuring-access-control-policy-for-a-service-provider/

[4] https://medium.com/@johann_nallathamby/wso2-iam-workflows-ee5914868a43

[5] https://is.docs.wso2.com/en/latest/learn/workflow-management/

[6] http://cdwijayarathna.blogspot.com/2016/04/making-use-of-wso2-identity-servers.html

[7] https://www.yenlo.com/blog/advanced-bpmn-workflows-in-wso2-identity-server