Skip to main content

Configure WSO2 Identity Server for single sign on with Moodle - Part II

User provisioning and attribute profile mapping with Moodle and WSO2 Identity Server 


This is the continuation of how to configure SAML2 Web SSO with WSO2 Identity Server and Moodle. I will guide you on how the attribute mappings and user provisioning can be done using WSO2 Identity Server and Moodle.

In order to do this we need to make sure that the attributes on the WSO2 Identity Server maps with the corresponding attributes in Moodle. This plugin provides the capability to auto provision users in Moodle. If a new user who is not registered in Moodle but is registered in the WSO2 Identity Server needs to be created in Moodle we can make use of these mappings.

Let's get started on the configurations.

First let's carry out the configs on the moodle end.

1) Same way as we did in the post [1]. Navigate to the Moodle's authentication plugins section and select the Settings of the OneLogin SAML SSO Authentication plugin.

2) Check the following two options.
  • Create user if not exists
  • Update user data

3) Next we need to do the attribute mappings. Provide the WSO2 identity Server claims which you want to map with the attributes on Moodle. Refer the below mapping which i created as an example.

Username - http://wso2.org/claims/displayName
Email Address - http://wso2.org/claims/emailaddress
First Name - http://wso2.org/claims/givenname
Surname - http://wso2.org/claims/lastname
Role - http://wso2.org/claims/role

4) Set the role mappings to the admin role as below. You can see what the new configurations look like now on the Moodle end.


Save the configuration.

Now let's configure the Identity server to pass these attributes in the SAML response over to the Moodle end so the mappings can happen correctly.

1) Log into the WSO2 Identity Server and edit the service provider configuration.

2) Expand the claim configuration section and add the following local claims. You can enable the ones you want to retrieve from the users as mandatory claims so that they will be automatically set on the Moodle's end. You can read more about mandatory claims and claim mappings here. [2]

Add the claims as indicated in the image below


3) Save the configurations.

Note - In order to map the site administrator of Moodle to the admin user of the Identity Server make sure that all the user attributes in the profile of the admin user are exactly identical to the Moodle admin user which you created in Moodle initially.

Let's try it out

First let's log in as the admin user.

Navigate to the url http://localhost/moodle/ which will redirect you to the Identity Server. Provide the Identity Server admin credentials. You will see you are successfully logged in as the admin user of Moodle.


Now let's see how Moodle will provision and auto create new users which are available on the WSO2 identity Server in Moodle automatically.

1) Add a new user in the WSO2 Identity Server. You can refer the documentation [3] on how to add a new user to the Identity Server.

2) Login to Moodle using that user. I created a user named moodleuser in the WSO2 Identity Server and assigned the user to the role Application/moodle_php_saml in order to test this scenario.

3) You will be prompted to enter the missing attribute values which Moodle needs for the user creation.


4) Submit after entering the details. Then you will be successfully logged into Moodle.

5) Let's now verify if the attributes have been mapped correctly. For that go to Profile -> Edit Profile of the logged in user. As you can see per the below image the attributes have been mapped successfully without additional configuration on the Moodle end.


We have successfully configured SAML2 Web SSO with Moodle and completed the attribute mappings for user provisioning. I hope this post was helpful! 
References

[1] http://shenavid.blogspot.com/2017/10/configure-wso2-identity-server-for.html
[2] https://docs.wso2.com/display/IS530/Configuring+Claims+for+a+Service+Provider
[3] https://docs.wso2.com/display/IS530/Configuring+Users#ConfiguringUsers-Addinganewuserandassigningroles

Comments

Post a Comment

Popular posts from this blog

Processing large payloads with the esb script mediator iteratively

Overview WSO2 ESB uses Rhino engine to execute JavaScripts. Rhino engine converts the script to a method inside a Java class. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters, since the Script mediator converts the payload into a Java object. However, you can use the following alternative options to process large JSON data volumes. The script mediator which is used in ESB is powered by the Rhino engine. Therefore, when processing large JSON data volumes, the code length must be less than 65536 characters which is a limitation in the script mediator being used in the esb versions less than 5.0.0. In ESB 5.0.0 there is a higher capability to process larger payloads using script mediator. In order to process such large payloads we can follow the below two approaches. 1. Replace the javascript tranformation logic using java code by writing a custom mediator. [1] 2. Break down the large payload and execute them as sections using
Post a Comment
Read more

Exposing a SOAP service as a REST API

In this post i will be explaining how we can transform a SOAP based backend to receive requests in a restful manner through the WSO2 API Cloud. Steps. First log into the WSO2 Cloud and navigate to the API Cloud. In the API cloud select the option to add a new API. We will be creating an API to demonstrate an invocation to the backend soap service ws.cdyne.com/phoneverify/phoneverify.asmx?wsdl Give a name, context and version to the API and add a resource name with a GET Method. The resource name can be anything which you like since we will invoke the actual service usiing a custom sequence. Mention the URI template as indicated in the below screenshot. Next go to the implement tab. And select the endpoint type as HTTP/SOAP Endpoint and specify the endpoint as http://ws.cdyne.com/phoneverify/phoneverify.asmx. There is an important step we need to do here. We need to set the SOAP version for this request. In order to do that we need to select the advanced option for the e
2 comments
Read more

Invoking external endpoints using the call mediator in wso2 api manager

Introduction In API Manager if you need to do any service chaining use cases the call mediator comes in handy. If you need to use the response received by invoking one endpoint and then use it to invoke another endpoint you can use the call mediator in API Manager. The call mediator behaves in a synchronous manner. Hence, mediation pauses after the service invocation and resumes from the next mediator in the sequence when the response is received. You can read more about the call mediator in the wso2 esb documentation [1] . In api manager 1.10.0 the call mediator works in the blocking mode. Prerequisite Before we can use the call mediator in API Manager 1.10.0 we need to make the following changes to some configs. We need to comment the jms transport sender in axis2_blocking_client.xml found in the location APIM_HOME/repository/conf/axis2. This will resolve the jms sender initialization issues.   <!--transportSender name="jms"                      class
1 comment
Read more