Application Authorization using WSO2 Identity Server — 2 — Using Template Policies
In the last post I provided an introduction on engaging access control policies in authentication flow (application authorization) in WSO2 IS 5.3.0 and a trivial use case where for one application users are denied always. Now we’ll see how we can use template XACML policies provided with WSO2 IS 5.3.0 to achieve the frequent use cases.
Let’s assume that there’s an organization with hundreds of employees divided into separate departments such as Engineering, Sales, HR, Marketing and Finance. This organization has some internal applications serving different purposes, and they all are SSO’ed with WSO2 Identity Server. Until now these applications didn’t have any sensitive information (at least for the employees). However, recently the management has decided to introduce Salesforce to manage the sales of this company. The management doesn’t need to allow any employees other than the sales team to access the salesforce. However, they still want salesforce to be SSO’ed with the other apps to make the life easy for the sales team.
Let’s assume that the service provider for salesforce is registered as “SalesforceSP” in the IS management console, and the role of sales team is “sales”. Following are the steps to enable the authorization.
- Login to management console as a user with admin permission
- Go to Entitlement -> PAP -> Policy Administration. This should show a list of policies available at IS.
- Locate the policy named “authn_role_based_policy_template” and click on its name to edit and customize it.
Now you’ll see the XML based policy in the policy editor. You’ll see some placeholders there in all capitol letters which you can configure.
As the first step locate the following and edit it to have a different policy name for our policy.
We may change it as,
You may also change the description under <Description> tag to have a meaningful one describing what your policy is about.
Then locate the “SP_NAME” placeholder (in the Target section) and replace that with “SalesforceSP” which is the one you used as your service provider.
This template policy authorize the users who are in at least one of the ROLE_1 or ROLE_2. But in our case we need to allow only “sales” role. So you can rename “ROLE_1” placeholder to “sales” and remove the section for “ROLE_2”.
Once you did the above mentioned changes, your policy will be similar to below,
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="authn_role_based_policy_template" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
<Description>This policy template provides ability to authorize users to a given service provider(defined by SP_NAME) in the authentication flow based on the roles of the user (defined by ROLE_1 and ROLE_2). Users who have at least one of the given roles, will be allowed and any others will be denied.</Description>
<AttributeDesignator AttributeId="http://wso2.org/identity/sp/sp-name" Category="http://wso2.org/identity/sp" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
<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="true"></AttributeDesignator>
<Rule Effect="Permit" RuleId="permit_by_roles">
<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"/>
<Rule Effect="Deny" RuleId="deny_others"/>
- Save the policy. You should now see the new policy is created with the name you provided. (The template policy will still be there unchanged for later use)
- Click “Publish to My PDP” next to the policy
- In the next page, leave the default values and click “Publish”
- Go to PDP -> Policy View and confirm the policy is listed there as published.
- Now go to the Service provider you registered and edit it to enable authorization as below.
That’s it. You have successfully enabled the authorization! You can now try logging in with non-sales users and see that you get an authorization failure page where for sales role users you can successfully login.
Similar to above you can use the template policies to authorize users based on,
- Time of day
- User attribute (claim)
- Oauth Scope
Let’s see more on those policies and few more advanced cases in next posts.