Microsoft Azure AD

This document describes the steps required to activate SSO on your Screen account using the SAML protocol with Microsoft Azure AD. For the time being, the OAuth2 protocol is not supported.

SSO can also be combined with User Provisioning through the SCIM protocol.

Prerequisites for activating SSO for your Screen account:

1. You must have an Enterprise or Plus account.
2. You must have admin rights for your Screen account.
3. You must identify the person on your end who will be able to implement the required configuration changes on your Microsoft Azure AD account, i.e. your system administrator.

Important considerations:

• Account-wide failure to login may occur for your users during the configuration process. Reversing the SSO activation on the account can be done at any time if the configuration fails.
• At any given time, even while the SSO configuration is active, it is possible for an admin to log into the account using email and password credentials by using one of the following URLs:
  • https://www.codingame.com/work/login?forcePassword (US site)
  • https://www.codingame.eu/work/login?forcePassword (EU site)
• You may want to test drive the integration on a test Screen account first. In that case, contact your Screen account manager to set up this test account.

SSO Configuration is generally divided into the following steps:

1. Activate SSO Configuration
2. Add User Provisioning

Activate SSO Configuration

1. Open a ticket with the CoderPad support team asking for SSO activation and, possibly, user provisioning.

2. The support team will send you back three URL parameters related to SSO:

• SP Entity ID
• SP Assertion Consumer URL
• SP Metadata URL

  And two parameters related to user provisioning if requested:

• SCIM Base URL
• SCIM Secret Token

4. Configure an Enterprise application in Azure AD corresponding to Screen:

• Option: “Create your own application”

• Option: “Integrate any other application”

5. Activate SSO with SAML for this application. Edit the Basic SAML Configuration as follows:

• Identifier (Entity ID) = SP Entity ID (from the CoderPad support team)
• Reply URL (ACS URL) = SP Assertion Consumer URL (from the CoderPad support team)
• Leave the other fields empty

6. Edit the Attribute & Claims and add a new claim:

• Claim name = User.Email
• Value = user.userprincipalname

7. For testing purposes:

• Add a user to the application in Azure AD. As an alternative you can add a group containing your test user.
• Invite the same user to your Screen account

8. Send back the Federation Metadata XML file to the CoderPad support team. You can access this file in the third section of the SSO setup page.

9. Contact CoderPad support to set up a meeting between one of our engineers and your system admins. During the meeting, CoderPad will activate SSO on your account and you will be able to check that the test user can connect through SSO. Any final adjustments can be made in real time during this call.

10. From now on, any user added to both the Azure AD application and the Screen account will be authenticated through Azure AD.

✅As adding users on both sides can be cumbersome and counterproductive, you may want to activate user provisioning as well on your Azure AD instance.

Adding User Provisioning

Once SSO has been activated, User Provisioning can be turned on using the SCIM protocol:

1. From the Azure AD application, select Provisioning and then Get started:

2. Select Automatic provisioning mode

3. Add the following parameters:

• Tenant URL = SCIM Base URL (from the CoderPad support team)
• Secret Token = SCIM Secret Token (from the CoderPad support team)

4. The Test Connection action should be working correctly at this point.

5. Edit the provisioning Mappings:

• For Provision Azure Active Directory Groups, keep the default values:
  • Enabled: Yes
  • Target Object Actions: Create, Update, Delete
  • Attribute Mappings: display
  • Name, members
• For Provision Azure Active Directory Users, update the Attribute Mappings:
  • Enabled: Yes
  • Target Object Actions: Create, Update, Delete
  • Attribute Mappings:
    • userPrincipalName = userName (i.e. the login email)
    • Switch([IsSoftDeleted]…) = active
    • givenName = name.givenName
    • surname = name.familyName

❗Make sure you clear the user attribute mapping before you update it. Any mapping with [type eq…] — i.e. addresses[type eq "work"].country — will make the SSO crash. The library we use doesn’t support payloads that include any value selection filters (like [type eq….]), so you will need to ensure they are removed.

6. Add users and groups to the application:

• Users added directly will be created with no permissions on your Screen Account
• Groups allow to define a common set of permissions automatically set on the users of that group

7. From the provisioning menu:

• Start the provisioning
• Refresh & wait for “Current cycle status: Initial cycle completed”

8. Send a final request to the CoderPad support team specifying the Screen permissions you require for each group attached to the Azure AD application. This can be done during the meeting as well to speed up the process.

9. From now on users added to your groups will be automatically created in Screen with the proper set of permissions.