Gayan Madusanka

Implementing an authorisation model for federated users by leveraging the WSO2 Identity Server

In this post we explore leveraging the WSO2 Identity Server to create an authorisation model for federated users of an organisation. This technical document provides a step-by-step guide to achieving the above requirement.

wso2-is
Background and Motivation

Organisation ABC maintains two Software-as-a-service (Saas) applications. They are Amazon Web Services (AWS) and Salesforce. To access the AWS application, the concerned user must have a set of permissions that are bundled with a user role named as ‘Tech-Group’. Similarly, in order to access the Salesforce application, the concerned user must have a set of permissions that are bundled with the user role defined as ‘Non-tech Group’.

XYZ is a partner organisation to the mother organisation – ABC. David works as a manager for XYZ and has been assigned a ‘Manager’ login. John works as an engineer for XYZ and has been assigned an ‘Engineer’ login respectively

 

Requirement and Use-Case

Although David and John are both employees of XYZ, both of them are required to access applications that are  provided by ABC, with limitations to appropriate permissions and user roles only.

David, who is a manager, should be able to access the Salesforce application during work hours (9.00 am to 6.00 pm), but also with complete restrictions to accessing the AWS application.   

Similarly John – who is an engineer – should be able to access the AWS application during extended work hours (9.00 am to 10.00 pm) but completely restricted from accessing the Salesforce application.

 

High Level Design
Fig 1: High level design

(Fig 1: High level design)

Fig 2: High level design

(Fig 2: High level design)

 

  1. Users who require to access AWS applications will directly communicate with the Identity Provider (IDP) of organisation ABC. (Please note: AWS utilises an IDP initiated Single Sign On (SSO) where the user-agent directly communicates with the IDP.
  2. IDP related to organisation ABC federates the request to the IDP of organisation XYZ. Resultantly, the log in page of organisation XYZ will be prompted to the user. As soon as the user enters his user credentials, a Security Assertion Markup Language (SAML) response will be pushed to the IDP of ABC.
  3. Following ABC receiving the relevant SAML response, the user in concern will be provisioned to ABC with role mapping in a just-in-time (JIT) manner
  4. At the end of the authentication flow eXtensible Access Control Markup Language (XACML) based Policy Decision Points (PDP)  will conduct an authorisation check.
  5. As a final step, the AWS application will receive and SAML response. Similarly the Salesforce application will also follow the same flow except that it utilises a ‘Service Provider’ initiated SSO.

This post provides a step by step guide to achieving the above requirement using WSO2 Identity server.

Section 01: Simulating organisation XYZ using an Identity Server instance

By default all WSO2 products run on HTTPS port 9443 and HTTP port 9763 [1]. To carry out this exercise it is necessary to run two separate identity server instances. If you happen to be running both instances upon the same machine – change the port offset of one of the instances. FOr the purpose of this exercise I will be using an identity server instance running on port offset+1 to simulate organisation XYZ.

*Special requirement relating to Salesforce: Salesforce requires usernames in the form of email usernames. If you happen to be using Identity 5.3.0 use [6] to enable email usernames. If you are using Identity Server 5.5.0 use [7] to enable email usernames.

*Special requirement relating to AWS: AWS expects role claims within a particular format. Therefore, make the change MultiAttributeSeparator value ‘,’ to ‘#’ from <product_home>/repository/conf/user-mgt.xml

 

Step 01: Create the following two roles in the management console

  • Engineer
  • Manager
Fig 3: create new user role

(Fig 3: create new user role)

 

Step 02: Create the following two users in the management console and assign their respective user roles –

  • john@xyz.com – engineer role
  • david@xyz.com – manager role
Fig 4: add new user

(Fig 4: add new user)

(Fig 5: assign respective user roles)

(Fig 5: assign respective user roles)

Update the user profiles of both users as illustrated below. Please refer [5] to obtain a value for IM

Fig 6: update user profiles

(Fig 6: update user profiles)

Step 03: Register Service Provider with SAML Inbound [2]

  • Issuer: ABC 
  • Assertion Consumer URL: https://localhost:9443/commonauth

Make a note of the value of Issuer as this will come in use when registering the Identity Provider.

Fig 7: Register new service provider with SAML inbound

(Fig 7: Register new service provider with SAML inbound)

 

Step 04: Add claim configuration for service provider

  • Select the following from the ‘requested claims’ configurations
    • http://wso2.org/claims/role
    • http://wso2.org/claims/emailaddress
    • http://wso2.org/claims/im\

http://wso2.org/claims/role is useful to carry out authorisation checks where http://wso2.org/claims/emailaddress and http://wso2.org/claims/im are required for AWS console login.

Fig 8: claim configurations

(Fig 8: claim configurations)

 

Section 02: Simulate organisation ABC from another Identity Server instance

To illustrate this section I will be using an Identity Server instance running on the default port – 9443

Step 01: Create two roles tech-group and non-tech-group

Fig 9: add ‘tech-group’ role

(Fig 9: add ‘tech-group’ role)

Step 02: Add Identity Provider with name XYZ [4]

Fig 10: Add identity provider

(Fig 10: Add identity provider)

Step 03: Under Role Configuration add below role mapping

Mapping is as follows:

  • Engineer → tech-group
  • Manager → non-tech-group
Fig 11: Mapping user roles

(Fig 11: Mapping user roles)

Step 04: Under ‘federated authenticators’ expand SAML2 Web SSO Configuration [3][4]

As mentioned in – Step 03, section 01-  Service Provider Entity Id should be the same as Issuer value.

  • Service Provider Entity Id: ABC
  • Identity Provider Entity Id: localhost
  • SSO URL: https://localhost:9444/samlsso
Fig 12: configure SAML2 Web SSO Configuration

(Fig 12: configure SAML2 Web SSO Configuration)

 

Step 05: Expand Just-In-Time provisioning and enable JIT for Primary user store

Fig 13: configure JIT provisioning

(Fig 13: configure JIT provisioning)

Step 06: Configure AWS application and SalesForce application as SAML inbound service providers

  • Service Provider name: AWS
  • Issuer: urn:amazon:webservices
  • Assertion Consumer URL: https://signin.aws.amazon.com/saml
  • Enable Response Signing: checked
  • Enable Attribute Profile: checked
  • Include Attribute in the Response Always: checked
  • Enable Idp Initiated SSO: checked
Fig 14: Configure AWS application and SalesForce application as SAML inbound service providers

(Fig 14: Configure AWS application and SalesForce application as SAML inbound service providers)

 

  • Add claim configuration as below. Please check [5] for more information.
  • https://aws.amazon.com/SAML/Attributes/Role → http://wso2.org/claims/im
  • https://aws.amazon.com/SAML/Attributes/RoleSessionName → http://wso2.org/claims/emailaddress
Fig 15: setting claim configurations

(Fig 15: setting claim configurations)

Similarly, configure Salesforce application as follows:

  • Service Provider Name: SalesForce
  • Issuer: https://saml.salesforce.com

In order to get a value for Assertion Consumer URL, please refer [8].

Fig 16: configure Salesforce application

(Fig 16: configure Salesforce application)

Step 07: Configure Local and Outbound Authentication. Configuration for both Service Providers registered for AWS and SalesForce applications can be viewed here [3].

  • Federated Authenticator : XYZ-IDP
  • Enabled Authorization: checked
Fig 17: Configure Local and Outbound Authentication

(Fig 17: Configure Local and Outbound Authentication)

Section 03: Configure authorisation with XACML

WSO2 Identity Server 5.3.0 onwards supports engaging XACML policy in the authentication flow [9]. In this use case we are using XACML policies to implement an authorisation model.

Our requirement is – employees provisioned with a tech-group role should be able to access AWS application during (9.00AM to 10.00PM) and employees assigned with a non-tech-group role should be able to access SalesForce application during (9.00AM to 6.00PM).

Fig 18: Policy administration interface

(Fig 18: Policy administration interface)

 

In the Policy Administration UI, select the template:  authn_time_and_role_based_policy_template and modify values accordingly

  • PolicyId: authn_time_and_role_based_policy_aws
  • http://wso2.org/identity/sp/sp-name: AWS
  • http://wso2.org/identity/identity-action/action-name: authenticate
  • http://wso2.org/claims/role: tech-group
  • <AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#time“>09:00:00</AttributeValue>
  • <AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#time“>22:00:00</AttributeValue>

The idea is in order to authenticate with AWS Service Provider, the user must have been assigned tech-group role.

Fig 19: modifying values of the policy administration template

(Fig 19: modifying values of the policy administration template)

Similarly add another policy with below values

  • PolicyId: authn_time_and_role_based_policy_salesforce
  • http://wso2.org/identity/sp/sp-name: SalesForce
  • http://wso2.org/identity/identity-action/action-name: authenticate
  • http://wso2.org/claims/role: non-tech-group
  • <AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#time“>09:00:00</AttributeValue>
  • <AttributeValue DataType=”http://www.w3.org/2001/XMLSchema#time“>18:00:00</AttributeValue>

Once complete, add both policies publish to PDP. Now you are done with all configurations. See Section 04 to test it.

Section 04: How to Try It

Step 01: Since AWS utilises IDP initiated SSO you can type the below URL directly on User-Agent (your browser window)

https://localhost:9443/samlsso?spEntityID=urn:amazon:webservices 

You will be redirected to organization XYZ login page. Enter the username: john@xyz.com and necessary password.

Fig 20: Log in interface

(Fig 20: Log in interface)

You will see that the user is successfully authenticated with the AWS application because he has an engineer role which maps to tech-group.

Fig 21: Successful log in

(Fig 21: Successful log in)

Same way if you enter credentials of David authorisation will fail and will not be able to log into the AWS application.

Fig 22: Log in attempt with unauthorised user
Fig 23: failed log-in attempt

(Fig 23: failed log-in attempt)

Similarly you can try Salesforce application with URL https://<your domain>-dev-ed.my.salesforce.com?so=00D7F000006jKBO (Same as Assertion Consumer URL of salesforce SAML SSO Configuration)

You will be redirected to login page of XYZ.

If you enter credentials of David, authentication will be successful since he has a manager’s role which maps to non-tech-group.

If you enter credentials of John authorisation will fail since he does not the have necessary role to perform authorisation checks.

Fig 24: Salesforce enable SSO login

(Fig 24: Salesforce enable SSO login)

Fig 25: Logging in to Salesforce application with David’s user credentials

Gayan Gunawardana

Technical Lead | Mitra Innovation