Authenticating users with OpenID Connect

Authenticating users with OpenID Connect

Authenticating users with OpenID Connect

With the standard setup users are authenticated internally in Crosser Cloud. If you already have a directory server where your users are registered you can use this for authenticating users with Crosser Cloud through Open ID Connect. To set up authentication with external directory servers you need to configure one or several Identity providers. An identity provider manages users from one or several domains. When a user tries to login with an email address containing a domain which belongs to one of the configured identity providers an authentication request will be sent to the external directory server, checking whether the user has a role that should give acces to Crosser Cloud. With the identity provider configuration you can also map roles and groups in the external provider against permissions in Crosser Cloud.

Note: You can only configure identity providers for domains that have been registered with your organization by Crosser.

Setting up an Identity Provider (wizard)

Identity providers are configured on the Organization page, found in the user menu in the top right corner of the Crosser Cloud interface. On that page, select Identity providers in the left-hand menu. This opens up a list of currently defined identity providers, if any, and also allows you to add new providers.

When clicking on + Add Identity Provider a wizard opens up which takes you through three steps to complete the configuration.

Step 1: Basic information

The following settings are available:

NameYesThe name of this configuration. Shown in the Identity provider listing.
DescriptionNoOptional description.
Client IdYesThe Client Id for Crosser obtained from your directory server.
Client SecretYesThe Client Secret for Crosser obtained from your directory server.
AuthorityYesThe URL to your Open ID Connect endpoint.
User Name ClaimYesThe name of the claim that contains the user email address.
Get Claims From User Information EndpointNoFetch additional user information from external directory which was not include included in token due to size.
Crosser RoleNoRole in the external directory required to get access to Crosser Cloud. If left empty all users will get access.
DisabledNoIf checked this identity provider is disabled and no requests to the external authentication server will be made.

Step 2: Domains

This step is used to map this configuration against one or several user domains. The domains listed here must be assigned to this organization by Crosser. A domain can only be managed by one identity provider, hence any domains already assigned to an identity provider will not be available for selection.

Step 3: Role Mapping

In the final step you can map roles and groups in the external directory against permissions in Crosser Cloud. Each external role can be mapped to one or several Crosser permissions and multiple external roles can be mapped to the same Crosser permissions. To add a new mapping enter a new name in the Role Name field and check one or several permissions in the list. Then click Add. All current mapping are shown in the list at the bottom of the page and here you can also modify and delete existing mappings.

Modifying Identity Provider configurations

Clicking on the edit icon to the right of an existing identity provider configuration in the list opens up the wizard so that you can make changes. Save your changes with the Update button or by clicking somewhere in the UI that will make you leave the wizard, you will then be asked if you want to save or discard your changes.

Using Azure ActiveDirectory as identity provider

This section describes how you configure your Azure AD for use with Crosser Cloud.

Initial setup in Azure

  1. Configure Azure groups to be used for access rights in Crosser Cloud:
    • Go to Azure Active Directory -> Groups and create the groups you want to use to set up access rights in Crosser Cloud, or use any existing groups. At least one group is needed.
    • Write down the Object ID of the group(s) (this is a guid).
    • Assign the users that should have access to Crosser Cloud to the right groups.
  2. Create an App registration for Crosser Cloud:
    • Go to Azure Active Directory -> App Registrations and create a new App Registration. If you don’t have any other preferences choose Accounts in this organizational directory only (Standard Catalog only - Single tenant).
    • On the Overview page, write down the Application (client) ID and click on Endpoints and copy the URL in the OpenID Connect metadata document, but skip the part after v2.0/. The URL should look like this:<guid>/v2.0/
    • On the newly created app registration click Add a certificate or secret. Save the secret value (client_secret, which is auto generated), you will not be able to access it later.
    • Go to API permissions -> Add a permission -> Microsoft Graph -> Delegated permissions -> RoleManagement.Read.All and add it.
  3. Azure AD roles limit (optional):
    • Azure AD has a limit on the number of object IDs that it includes in the groups claim. The limit varies between token types as follows, 150 for SAML tokens, 200 for JWT tokens and 6 for Single Page applications. If a user belongs to more groups than this limit, then Azure AD will not include any group in the claims.
    • It is possible to make sure that this limit is not reached. One way is to only include groups assigned to the application which the user is part of. To add groups to the application:
      • On the Overview page and click on the link next to Managed application in local directory.
      • Go to Users and Groups and click on Add user/group
    • Go to Token configuration -> Add groups claim and uncheck Security groups and make sure only Groups assigned to the application is checked.

Setup in Crosser Cloud

From the setup in Azure you should now have the following:

  • client_id
  • client_secret
  • Endpoint URL

Follow these steps to setup a new Identity Provider in Crosser Cloud that uses your Azure AD:

  1. Create an Identity Provider, as described above
  2. Fill in the client_id and client_secret you saved above when creating the app registration
  3. Set the authority to the endpoint URL you saved above (<guid>/v2.0/)
  4. Set Username Claim to email.
  5. Check the Get Claims From User Information Endpoint checkbox.
  6. Enter the Group ID (as you saved above) of the group(s) that should be used to allow access to Crosser Cloud.
  7. Choose the domains you want to use with this AD.
  8. Use the Group IDs to associate users to the appropriate roles in Crosser Cloud.
  9. Press Finish
  10. Copy the Return URL.

Final setup in Azure

On the App Registration Overview -> Add redirect URI -> Add a Platform -> Web, put the redirect URL from Crosser Cloud into Redirect URI and press Configure.

You are done!
Users logging in to Crosser Cloud with a domain registered above will now be authenticated using your Azure AD.

    • Related Articles

    • Users and Permissions

      Users setup Users with the User permission can add new users and change user role assignments. This is done on the Organization page that can be found in the menu when clicking on your user name in the top right corner of the UI. If you don’t have ...
    • Flow sharing

      June 30, 2022 Flow sharing It is now possible to decide who gets access to your flows. By default new flows will only be accessible to the creator (owner) of the flow. For others to see or change (depending on permissions) your flows you must ...
    • Credentials

      Credentials Note: Permission to manage Credentials is needed to use the functionality described on this page. However, all users can use credentials when configuring modules in flows. The Credentials library is a central repository for storing ...
    • Universal Connectors

      Universal Connectors Introduction Universal Connectors are generic modules used to connect to REST APIs. Using the Universal Connector (UC) wizard you can build your own reusable modules to simplify getting or sending data from/to external APIs when ...
    • Securing HTTP and MQTT endpoints

      By default the integrated HTTP server and MQTT broker in the Node use unencrypted communication without authentication. In this article we will explain how you can configure your nodes with encryption and/or authentication. TLS & Certificates To ...