WSO2 Identity Server (IS) supports various authentication protocols, such as SAML2, OpenID and WS-Federation Passive, to seamlessly integrate different service provider applications according to standards. Once service providers are integrated with WSO2 IS, user authentication for service providers will be handled by WSO2 IS.
Although login is centralized, service providers might have the requirement to allow or restrict access for certain users by enforcing certain authorization rules. For example, an application from an HR service provider only allows users with an HR role to access the application and must deny access to other users.
In WSO2 IS, the XACML feature enforces different kind of WSO2 authentication and authorization in the login flow. For example, this blog post explains how to configure WSO2 IS to perform role-based authorization with XACML when a user tries to login to a service provider.
PICKUP DISPATCH is a web application configured to use the WSO2 IS for user authentication. Identity Server has two different type of users, manager and staff. A Manager user has the role assigned of manager and staff users has the role assigned of staff. Access to the web application should only be allowed to the manager and restricted to staff users.
To run the example in this WSO2 Tutorial you must have the following prerequisites in place:
- WSO2 Identity Server 5.10.0
- Apache Tomcat 0.29
- Sample web application – pickup-war
Step 1 – Configure Service Provider
- Configure the service provider for the pickup-dispatch application. Go to Service Providers > Click on Add > Select Manual Configuration Mode > Register a service provider called “pickup-dispatch”
- Expand Inbound Authentication Configuration > OAuth/OpenID Connect Configuration > Configure
- Register the call-back URL as
http://localhost.com:8080/pickup-dispatch/oauth2client
and click on Add.
- Write down the OauthClientKey and OauthClientSecret of the service provider for later use.
- Expand Local & Outbound Authentication Configuration > Select the Enable Authorization check box
- Click on Update to save the service provider configuration.
Step 2 – Configure XACML Policy
- Open Entitlement-> Policy Administration -> authn_role_based_policy_template
- This template is designed to authorize the user based on the user role in authentication flow
- Configure template:
- Replace the policy id with a unique name g“pickup-dispatch-role-based-access”
- Replace SP_Name with the name of the service provider “pickup-dispatch”
- Replace ROLE_1 with role “manager” (in this example, a user with the role manager only has access to the service provider app
- Remove the ROLE_2 section (in this example only one role is used, but multiple roles can be handled by extending the template)
- Save the policy > Publish to MyPDP
Step 3 – Create users and roles
- Create the roles manager and staff. Users and Roles > Add > Add New Role > Give the Role Name > Click Next > Give login permission > Click Finish
- Create manager and staff users and associate the manager role to manager and the staff role to staff. Users and Roles > Add > Add New User > Give username and credentials > Click Next > Assign roles > Click Finish”
Step 4 – Setup sample web app
- Extract the web app pickup-war to apache-tomcat/webapps
- Open dispatch.properties located at: pickup-dispatch/WEB-INF/classes
- Replace consumerKey and consumerSecret values with the OAuth client key and the OAuth client secret value of the previously created service provider. Update the value of scope to “openid internal_application_mgt_view”
- Start the tomcat server
Step 5 – Verify Login
- Add host mapping to localhost.com in etc/hosts file: 127.0.0.1 localhost.com
- Access the hosted web application:
http://localhost.com:8080/pickup-dispatch/index.jsp
- Login as a staff user who has the staff role assigned. The result would be authentication failed due to authorization fail.
- Login as a manager user who has the manager role assigned. The result would be login is successful with user role authorization.
Conclusion
WSO2 Identity Server provides out-of-the-box support to engage XACML policies in the authentication flow to enforce authorization requirements. XACML can not only be used to enforce role-based authorization, but also to enforce other fine-grained access control. For example, restricting access to a service provider within a certain time period, granting access to a service provider based on user’s claim values, et cetera.
If this blog sparks any questions for you don’t hesitate to leave a comment below the or contact us.
