Skip to main content

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

Introduction

Moodle is a learning platform designed to provide educators, administrators and learners with a single robust, secure and integrated system to create personalized learning environments.[1]. This is commonly used in the education sector and there might be occurrences where it would require to use SAML to login to Moodle instead of the default basic authentication. For this we would need to have an Identity Provider capable of issuing such SAML tokens and Moodle configured to accept the tokens in order to do the authentication

I will be discussing this in two parts.

Part I - How to configure moodle for SSO with WSO2 Identity Server
Part II - How to carry our user provisioning and attribute profile mapping with Moodle and WSO2 Identity Server

Let's see how this can be achieved using a SAML authentication plugin provided by one login.

Prerequisite 

You need to have a working version of Moodle installed. If you want to try this tutorial from scratch you can simply download and install Moodle on your machine by following the tutorial [2]

Let's get started

In order for Moodle to support SAML 2 SSO we need to install the One Login SAML SSO plugin into Moodle. You can find the jar which you can download and add as a plugin which is compatible with the Moodle version which you are using.

1) Download the One Login SAML plugin from this link [3]. The plugin files are found at the end of the link.

2) Go to the moodle dashboard and login as the administrator and browse to the site administration page.

3) Under plugins you will find an option to install plugins. Upload the downloaded zip file to it.


4) Next go to the installed plugin. You can find this added under Authentication plugins in the plugin section. Click on the settings option for the entry corresponding to OneLogin SAML SSO Authentication.

5) Under the identity Provider Configuration provide the following information so that the WSO2 Identity Server is used as the Identity Provider for this use case.
  • IdP Entity Id - localhost
  • Single Sign On Service Url - https://localhost:9443/samlsso
  • Single Log Out Service Url - https://localhost:9443/logout
  • X.509 Certificate - For this you need to specify the public certificate of the IDP. Since we are using the WSO2 Identity Server we need to provide the public certificate of the wso2carbon.jks keystore here. You can follow the blog post [4] on how to obtain it. You can use the below command.
keytool -export -keystore pathToKeystore -rfc -alias aliasNameForCertificate

6) Now the configuration on the moodle end should look like this.

7) Next under the Moodle's advanced settings set the Service Provider entity Id as below.




Now the configurations on the Moodle end is done. If you want to configure the attribute mapping in moodle at this stage you can refer the post [7] in order to do this and complete all the Moodle configurations with attribute mappings in one go.

If you are not configuring the attributes at this step then make sure the one login SAML plugin has not been enabled under the authentication plugins.

Next we need to register Moodle as a service provider on the WSO2 Identity server. Let's look at how we can do that.

1) Download the WSO2 Identity server.

2) After the installation navigate to the management console and add a new service provider. You can follow the documentation [6] on how to add a new service provider to WSO2 Identity Server.

3) Enter the following details for the configuration of the Moodle service provider. The SAML2 Web SSO related configurations can be found under the Inbound Authentication Configuration Section and update the configuration.

Service Provider Name
- moodle_php_saml
Issuer - moodle_php_saml
Default Assertion Consumer URL - http://localhost/moodle/auth/onelogin_saml/index.php
NameID format - urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
Enable attribute profile



Now all the configurations have been completed. Moodle has been configured to use WSO2 as the identity provider.

This setup won't be complete until we carry out the attribute mappings also correctly. Let's see how we can map Moodle's user attributes to the Identity Server so the users are provisioned correctly. I will be discussing about it in my next post [7].

Read more on how to carry our user provisioning and attribute profile mapping with Moodle and WSO2 Identity Server here.

References

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

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

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