About the Integration
By using the Azure AD integration, the employees will be able to log into MobieTrain without the need of an additional set of credentials. Also, by using your own authentication system, it will allow the users to quickly start learning, using an already familiar log in process.
What can be expected?
- Employees will be able to log into MobieTrain, through the client’s Azure AD login.
- Employee information will be updated in MobieTrain, according to what is received from Azure AD (Name, Email, Id, User Groups, etc.).
How does it work?
- Employee clicks a specific link, provided by MobieTrain;
- If he’s not logged in on Azure AD, the client’s login will appear for the user to input the credentials;
- After successful login and authorization, the Employee is redirected to the MobieTrain app;
- If the user doesn’t exist yet, then it is created and assigned to the right User Groups and Stores, as long as this information is set up.
- The same happens with User Groups and Stores. If the user comes in associated to a User Group or Store that doesn’t exist, then these are created and the user attached to them.
- If the user already exists, then his information is updated;
- The user will then be able to use the MobieTrain app, and he’s ready to start learning.
Manual Updates
Usually, all the User Groups and Stores information is created/updated from Azure AD. There are some exceptions, though. When manual changes are made in MobieTrain’s CMS, the following things are not updated:
- Removal of User Group assignments to Users. Only User Groups added via SSO integration will be removed via SSO integration.
- User Groups names. If the User Group name is changed manually, on the MobieTrain CMS, it is not changed.
- Removal of Stores assignments to Users. Only Stores added via SSO integration will be removed via SSO integration.
- Store names. If the Store name is changed manually, on the MobieTrain CMS, it is not changed.
Setting Up Azure
Information you need before starting
Before starting your configuration, make sure that you received, from MobieTrain, the following information:
- Identifier (Entity ID). Should look like this:
https://id.mobietrain.com/external/company123/id123/saml/metadata.xml - Reply URL (Assertion Consumer Service URL). Should look like this:
https://id.mobietrain.com/external/company123/id123/saml/cb - Sign in URL. This is the URL you’ll use to log into MobieTrain, that should be shared with all the employees that will be using the MobieTrain app. Should look like this:
https://app.mobietrain.com/login/external/company123/id123 - CMS URL. Should look like this:
https://cms.mobietrain.com/login/external/company123/id123
These are just examples, make sure you receive the links specific for your account from your Customer Success Manager.
After you set up Azure
After you follow the steps below, to set up Azure AD, you should return some information to MobieTrain, so that we can finish the integration on our end:
- App Federation Metadata URL
- Login URL
- Logout URL
- Certificate
With this elements, we’ll finish the integration and you can then test it, and go live.
Setting up Enterprise Application
Start by creating a new Enterprise Application:
Then, setup Single Sign On for the newly created Enterprise Application:
Send the following information to MobieTrain:
- Base 64 Certificate (if you send it through email, you should put it inside a zip file, since some email servers have policies in place that don't allow access to these kinds of files);
- App Federation Metadata URL;
- Login URL;
- Logout URL.
After you send this information, MobieTrain will perform all the changes required, and once you have the ok, your employees can start using the login URL to use MobieTrain.
In the case of the existence of any policy in our organization that requires different values to be filled in these fields, please contact your Customer Success Manager.
Custom Assertions - User Groups and Stores
In order to have custom Groups and Stores being sent to MobieTrain, custom SAML Assertions can be added, allowing the Groups and Stores to be automatically created on MobieTrain. That way, the user logging into MobieTrain will be attached to the right groups and stores.
To configure these, on “Attributes & Claims”, click on “Edit”:
Then, click on “Add new claim”.
User Groups
For Groups you should use the “namespace”: http://id.mobietrain.com/saml/2023/01/identity/claims/group.
- The “name” attribute should be: name-XX (where XX is a two digit integer ID, padded with zeros, e.g.: 01, 02, 03… ) for setting the name of the group.
- For setting the group type, the name should be type-XX, for the group ID, id-XX.
- At least id-XX or (not exclusive) name-XX should be set. Upon receiving those claims, the ones with the same ID will form a group inside MobieTrain application.
It’s important to understand that for each User Group that you want to have in MobieTrain, you can set up between 1 and 3 claims, depending on how complete you want the information to be. For each User Group you can have (* means one of these claims is mandatory. So, you can have one or the other.):
- Type
- Name *
- ID *
User Group Configuration Example
Suppose you want to create User Group for Job Position, you can set it up like this:
Claim 1
- Name: type-01
- Namespace: http://id.mobietrain.com/saml/2023/01/identity/claims/group
- Source attribute: Job Position
Claim 2
- Name: name-01
- Namespace: http://id.mobietrain.com/saml/2023/01/identity/claims/group
- Source attribute: user.jobposition (this should be the field that you want to send)
Claim 3
- Name: id-01
- Namespace: http://id.mobietrain.com/saml/2023/01/identity/claims/group
- Source attribute: user.jobpositionid (this should be the field that you want to send as id)
As you can see, for all the claims, you have the suffix -01 which will tie everything together.
When a user logs into MobieTrain, with this information filled, it will generate a User Group called Job Position: Manager with an ID, for example 1234.
In the CMS, you’ll find the user group in the form type + “: “ + name.
You can send as many claims as you want to fulfil your User Groups needs.
If there’s not an ID claim, the name claim will be used as an id. This means that, in this case, if the job position changes its name, the system will consider it as a new User Group.
Stores
For Stores you should use the “namespace”: http://id.mobietrain.com/saml/2023/01/identity/claims/store.
-
The “name” attribute should be: name-XX (where XX is a two digit integer padded with zeros, e.g.: 01, 02, 03… ) for setting the name of the store.
-
For setting the store country, the name should be country-XX, for the store ID, id-XX.
-
At least id-X or (not exclusive) name-XX should be set. Upon receiving those claims, the ones with the same ID will form a store inside MobieTrain application.
It’s important to understand that for each Store that you want to have in MobieTrain, you can set up between 1 and 4 claims, depending on how complete you want the information to be. For each Store you can have (* means one of these claims is mandatory. So, you can have one or the other.):
- Type
- Name *
- Country
- ID *
Store Configuration Example
To configure a Store you can set it up like this:
Claim 1
- Name: type-01
- Namespace: http://id.mobietrain.com/saml/2023/01/identity/claims/store
- Source attribute: Store
Claim 2
- Name: name-01
- Namespace: http://id.mobietrain.com/saml/2023/01/identity/claims/store
- Source attribute: user.store (this should be the field that you want to send as store)
Claim 3
- Name: country-01
- Namespace: http://id.mobietrain.com/saml/2023/01/identity/claims/store
- Source attribute: user.storecountry (this should be the field that you want to send as country, and it should be in the Alpha-2 format, 2 letters)
Claim 4
- Name: id-01
- Namespace: http://id.mobietrain.com/saml/2023/01/identity/claims/store
- Source attribute: user.storeid (this should be the field that you want to send as id)
As you can see, for all the claims, you have the suffix -01 which will tie everything together.
When a user logs into MobieTrain, with this information filled, it will generate a Store called Job Store: Paris with an ID, for example 1234, and a country FR.
In the CMS, you’ll find the store in the form type + “: “ + name.
If there’s not an ID claim, the name claim will be used as an id. This means that, in this case, if the store changes its name, the system will consider it as a new Store.
Some Claims Parsing Examples
In the table below, you can find examples of how the claims are going to be interpreted by MobieTrain.
F.A.Q.
- Is the Azure AD integration compatible with CNAME configuration (custom domain)? Yes. The only thing it should be taken into consideration is that the custom link that is used to log in through Azure AD will be slightly different, containing the client’s configured domain.
Comments
Please sign in to leave a comment.