All pages
Powered by GitBook
1 of 16

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Configure two-factor authentication

Make White Label supports two-factor authentication (2FA), such as Google's Authenticator app. The following procedure enables 2FA for your instance. End-users must complete the process by going to their profiles and using Google Authenticator or a similar app.

  1. Go to Administration > System Settings.

  2. Select Enabled from the Two Factor Authentication menu.

  3. For Two Factor Authentication app name (visible in Google Authenticator) enter the name you want to appear in the authentication app.

For more information, go to the .

Your instance now allows end-users to set up 2FA. Verify by clicking Leave administration and going to Profile > 2FA. When a user sets up 2FA, a window opens with the QR code for Google Authenticator or similar apps. Scan the QR code and enter the numeric code in the field.

user documentation on 2FA

Configure Single Sign-on

You can configure single sign-on (SSO) from the System settings page and from your Identity Provider (IdP). Make White Label's SSO options let you decide whether to create a new organization for new end-users or not. This provisioning lets your end-users sign in and automatically receive their own organization for billing purposes.

Your instance supports the following authentication standards:

  • OpenID Connect (OIDC) (OAuth 2.0-based)

  • SAML 2.0

Click any of the following for configuration information:

Microsoft Azure Active Directory
Okta SAML

Steps on Okta

  1. Log in to Okta and go to Admin > Applications > Applications.

  2. Click Create app integration and select SAML 2.0.

  3. Name your app and upload your icon.

  4. Click Next.

  5. Configure the following SAML settings including:

Setting
Description
  1. Click Show advanced settings and enter the following:

Setting
Description
  1. Enter the following attributes and click Next.

Name
Name format
Value
  1. In the Are you a customer or partner? field, select I'm an Okta customer adding an internal app.

  2. In the App type field, select This is an internal app that we have created

  3. Click Finish.

To locate your IdP login URL and certificate:

  1. Go to Admin > Applications > Applications and select your SAML SSO app. to access the necessary information.

  2. Go to the Sign on tab and click View SAML setup instructions.

Enable Single Logout

Leave unchecked

Signed requests

Optional

Other requestable SSO URLs

Optional

Assertion inline hook

Select None (disable)

Authentication context class

Select PasswordProtectedTransport

Honor force authentication

Select Yes

SAML issuer ID

http://www.okta.com/${org.externalKey}

Single sign-on URL

24.0.6

Audience URI (SP Entity ID)

1.28

Default RelayState

Leave this field blank

Name ID format

Select EmailAddress

Application username

Select Okta username

Update application username on

Select Create and update

Response

Select Signed

Assertion signature

Select Signed

Signature algorithm

Select RSA-SHA256

Digest algorithm

Select SHA256

Assertion encryption

Select Unencrypted

Optional:

If you want to encrypt assertions, you can select Encrypted and enter the following:

  • Encryption algorithm: AES256-CBC

  • Key transport algorithm: RSA-OAEP

  • Encryption certificate: Upload the .pem file you created earlier.

Signature certificate

Upload a .pem file of the Service Provider Certificate. You need to also upload this to the Service Provider Certificate field of your Make SSO configuration tab. These two certificates must be the same for your SSO implementation to work successfully.

profileFirstName

Unspecified

24.0.6

profileLastName

Unspecified

1.28

email

Unspecified

user.email

Configure single sign-on using OAuth 2.0 or SAML 2.0

Double-check your SSO configuration before you click Save on the SSO settings page. When you click Save, Make enables SSO with the settings you provided. and logs you out immediately. You cannot log in with your credentials anymore.

  1. Log in to your Make White Label instance.

  2. Go to Administration > System settings.

  3. Select an SSO type.

    1. None - default option indicating that SSO is turned off.

    2. OAuth 2.0

      1. Select this option for OpenID Connect (OIDC).

  4. Fill in the protocol-specific information as described in the tables following this procedure.

  5. Enter an IML resolve. The IML resolve maps necessary data such as ID, name, and email, between Make and your identity provider.

  6. Under SSO Options, define whether and how your instance assigns new users to organizations. You can choose from the following options:

    • Don't create a new organization.

      • This option only creates a new user. That new user has no access to the scenario editor or other features. You must manually add the new user to an organization.

    • Create a new organization and team.

  7. Click Save.

If you do not select a default team, users logging in through SSO will not be able to access any data. This is because all types of data within Make must belong to a team. If a user does not belong to any teams, they cannot work with Make . .

Make enables SSO with the settings you provided and logs you out immediately. You can now log in with your SSO provider credentials. At the same time, you receive an email with a one-time link, which you can click to disable SSO. Use the one-time link within 24 hours before it expires. After 24 hours you must contact your customer success specialist.

When logging in using SSO for the first time, you must use an account that has the same email address as the account that you used to configure SSO. Make sure that you assign the same email address to the user in your identity provider.

Open ID Connect (OAuth 2.0 settings)

The following fields appear once you select OAuth 2.0 from the SSO menu:

Field
Required
Description

SAML 2.0 settings

Field
Required
Description

Create your service provider primary key and certificate

Your Make White Label instance signs and verifies SAML 2.0 requests with the primary key and certificate that you provide.

Use openssl or similar as in the following example:

openssl req -newkey rsa:2048 -new -nodes -x509 -keyout key.pem -out cert.pem

This example creates two separate files that you can extract into the following fields:

  • Service provider primary key

  • Service provider certificate

Create URLs for your instance as a service provider

To configure SSO on your identity provider, you need to provide URLs. The following are examples using the base domain https://example.celonis.integromat.

Adjust them according to the domain of your instance.

  • SAML ACS URL: https://example.celonis.integromat.com/sso/saml

  • SAML Entity Information URL (also known as Audience Restriction URL): https://example.celonis.integromat.com/sso/saml

Create and enter Login IML resolve

To support a broad choice of identity providers (IdPs), Make lets you map values related to identifying users. The IML resolve maps the values from your IdP to Make's internal values by using IML, a JavaScript-based function notation. Your IML resolve must be specific to your IdP. You must map the following properties:

Field
Description

Example

In the following example, the resolve maps the following values:

Okta SAML

The following manual configuration creates a SAML SSO configuration for your Enterprise organization.

Prerequisites

  • Owner or admin role in an Enterprise organization

Service provider certificate and private key that you create

Supported features

This configuration supports the following:

  • Service provider initiated SSO

  • Single Log Out [optional]

Logging in using SSO

Once you configure SSO, your end-users don't use the default sign-in form. Instead, they use the dedicated SSO sign-in options.

  1. Go to your login URL.

  2. Click Sign in with SSO.

  3. Log in using your identity provider and consent to Make's access to your user data.

The user is now logged in. If the user was not assigned to your organization before, the system creates a new users account for them and assigns them to the selected default team.

If a user's email address already exists in the organization before you configure SSO, they do not have access to the organization's data. To solve this, delete the user from the organization and ask them to log in again using SSO.

Configuration steps

Before configuring SSO, you need to assign a namespace and create a service provider certificate and private key. These important steps provide information you need to enter later.

Create your namespace:

  1. Go to Administration > System settings.

  2. Scroll down to SSO Type.

  3. Under SSO type, select SAML 2.0.

Create your service provider primary key and certificate:

  1. Use openssl or similar. Mac users can use Terminal

  2. Enter the following command:

openssl req -newkey rsa:2048 -new -nodes -x509 -keyout key.pem -out cert.pem

This example creates two separate files:

  • key.pem

  • cert.pem

Locate these files and have them ready to upload later.

Service provider initiated SSO

  1. Go to the login page for your instance. Log out if needed.

  2. Click Sign in with SSO.

  3. Log in using your Okta credentials and consent to Make's access to your user data.

Troubleshooting

You can bypass SSO by going to https://xyz.onmake.com/admin/login and entering your credentials. Using the /admin/login page lets you return to the System settings page and adjust your configuration.

SAML

  • This option is similar to what happens to Make users on the public cloud. They receive their own organization and can create scenarios as they like.

  • Assign to an existing organization and team.

    • This option requires entering the organization ID number and team ID number. An example use case is users within the same company. Each new user joins the organization and can only access their assigned organization and team.

  • Scopes separator

    optional

    The character used between scopes, such as a space or a comma. If your separator is a space, use the spacebar on your keyboard.

    Authorize URL

    Yes

    URL obtained from your identity provider.

    Example: https://example.com/oauth2/v1/authorize

    Client secret

    Yes

    Obtained from your identity provider.

    IML resolve

    Yes

    Because both Make and your Identity provider use attributes such as username and email, you need to map these attributes using IML.

    For Open ID Connect:

    {"id":"{{sub}}","email":"{{email}}","name":"{{name}}"}

    Redirect URL

    optional

    The location where the identity provider sends the user once successfully authorized and granted access. Must be unique to your application/instance.

    IdP logout URL

    Yes

    A URL created by your IdP to enable Single Log Out (SLO). Leave this field empty to disable SLO.

    Login IML resolve

    Yes

    Because both Make and your Identity provider use attributes such as username and email, you need to map these attributes using IML.

    Redirect URL

    Optional

    The location where the identity provider sends the user once successfully authorized and granted access. Must be unique to your application/instance.

    Allow unencrypted assertions

    Optional

    Your IdP may not support SAML 2.0 assertions with encryption. Check with your IdP to determine whether you need to enable this option.

    Allow unsigned responses

    Optional

    Your IdP may not support a signed SAML 2.0 response. Check with your IdP to determine whether you need to enable this option.

    Sign requests

    Optional

    Your IdP may require a signed SAML 2.0 response. Check with your IdP to determine whether you need to enable this option.

    Audience

    Optional

    Optional field to define the intended target. Typically this is a URL but can also be formatted as any string of data.

    User Information URL

    Yes

    URL obtained from your identity provider.

    Example: https://example.com/oauth2/v1/userinfo

    Client ID

    Yes

    Obtained from your identity provider. Sometimes called Application ID.

    Token URL

    Yes

    required

    URL obtained from your identity provider.

    Example: https://example.com/oauth2/v1/token

    Login scopes

    optional

    Parameters used when accessing your identity provider.

    Service provider primary key

    Yes

    The private key used to sign requests. You can get this from your certificate authority or create your primary key using OpenSSL. Make can extract this from the following file formats:

    • P12

    • PFX

    • PEM

    Service provider certificate

    Yes

    An x.509 certificate you create. Make can extract this from the following file formats:

    • P12

    • PFX

    • PEM

    Identity provider certificate

    Yes

    An x.509 certificate created and stored by your IdP, for example, Google, Okta, or Microsoft Azure Directory. You can enter this information in the following ways:

    • Copy and paste from your IdP's UI.

    • Copy and paste from your IdP's metadata XML file.

    • Extract from any of the following:

      • P12

      • PFX

      • PEM

    IdP login URL

    Yes

    Also called an authorization URL. The IdP login URL is available from your IdP, for example, Google, or Okta. The IdP metadata typically contains this information in XML. The IdP metadata is usually downloadable from your Identity provider.

    email

    You can map this to any valid email.

    Note: Aliases and alternate email suffixes can create problems. Be sure to map the most appropriate email in your IML resolve.

    name

    Used as the user's name in the application.

    You can reuse email for this property.

    If left blank creates a user without a name that must be updated later.

    id

    External user ID

    Can be an integer or string but must be mapped to an identifier.

    Read more about teams
    {
    "email":"{{get(user.attributes.email, 1)}}",
    "name":"{{get(user.attributes.firstName, 1)}} {{get(user.attributes.last}}
    "id":"{{user.name_id}}"
    }

    Example: Setting up single sign-on with MS Azure Active DirectoryPage 1

    Microsoft Azure supports both OAuth 2.0 and SAML 2. Perform the following steps to connect Make with Azure Active Directory.

    OAuth 2.0

    1. Log in to your Azure Portal and open Azure Active Directory.

    2. Open App registrations and click New registration.

    3. Give the registration a name.

    4. Fill in the Redirect URL.

      • Find the Redirect URL In Make > Organization > Settings after you select an SSO type.

    5. Click Register.

    6. Note down the Application (client) ID.

      • Paste this ID into your Make settings.

    7. Go to Certificates and secrets and click New client secret.

      • Paste the secret value into your Make settings.

    8. Go to Overview and click Endpoints.

      • Paste the OAuth 2.0 authorization endpoint (v2) into the Authorize URL field in Make settings.

      • Paste the OAuth 2.0 token endpoint (v2) into the Token URL field in Make settings.

    9. Paste the following into the User information URL in Make settings.

    10. In Make, set up Login scopes and Scopes separator:

      • Login scopes: openid, profile, email

      • Scopes separator: space

    11. In Make, paste the following into User information IML resolve. This tells Make how to map user information received from Azure to information in Make database.

      • {"id":"{{id}}","email":"{{mail}}"}

    Instance level roles

    Your Make private instance has the following groups of instance-level permission roles:

    • System roles designed for the needs of administering the instance.

    • Developer roles designed for users who edit and create custom applications.

    • Support roles designed for those who provide customer support.

    The following charts provide the details of which specific permissions are enabled for each role.

    Steps on Make

    1. Go to Organization > SSO.

    2. Enter the following information from Okta into the IdP login URL and Identity provider certificate fields.

    1. In the Allow unencrypted assertions, select Yes.

    https://graph.microsoft.com/v1.0/me
    Admin - system roles
    Admin - developer roles
    Admin - support roles

    In the Allow unsigned responses, select No.

  • To allow the Sign requests, select Yes.

  • Click Save.

  • {"email":"{{get(user.attributes.email, 1)}}","name":"{{get(user.attributes.profileFirstName, 1)}}
    {{get(user.attributes.profileLastName, 1)}}","id":"{{user.name_id}}"}

    Manage login

    The System settings page lets you enable login features to enhance the security and integration of your Make White Label instance. The single sign-on (SSO) configuration supports a wide range of identity providers. You can also enable end-users to set up two-factor authentication for their accounts.

    Your Make White Label instance supports the following login options:

    • Default email and password login page

    • Single sign-on (SSO)

    • Two-factor authentication

    Admin - support roles

    Scope
    S1
    S2 (unrestricted)
    S3 (restricted)
    S4 (read-only)
    S2 (with extras)

    access

    Access to the admin portal.

    Yes

    Yes

    Yes

    Yes

    Yes

    access monitoring

    Access to monitoring.

    -

    -

    -

    -

    -

    access raw logs

    Access to confidential scenario data.

    -

    Yes

    Yes

    Yes

    Yes

    access trackman

    Access to the Trackman Service.

    -

    -

    -

    -

    -

    admins edit

    Access to admin editing.

    -

    -

    -

    -

    -

    apps approve

    Can approve apps.

    -

    -

    -

    -

    -

    apps commit

    Access to commit changes in apps.

    -

    -

    -

    -

    -

    apps edit

    Access to apps editing.

    -

    -

    -

    -

    -

    apps get

    Access to apps.

    Yes

    Yes

    Yes

    Yes

    Yes

    apps metadata edit

    Access to apps metadata editing. This permission is child permission of apps edit.

    -

    -

    -

    -

    -

    decrypt

    Decryption of confidential data.

    Yes

    -

    -

    -

    -

    decrypt common

    Decryption of "common data" for packages.

    -

    -

    -

    -

    -

    exceptions get

    Access to the error database.

    Yes

    Yes

    Yes

    Yes

    -

    extras add

    Access to adding extra data and operations.

    Yes

    -

    -

    -

    -

    internal services add

    Can assign internal services.

    -

    -

    -

    -

    -

    log as user

    Possibility to log in as a different user.

    Yes

    -

    -

    -

    -

    organization edit

    Access to organization editing.

    Yes

    -

    -

    -

    Yes

    organizations get

    Access to the list of all organizations.

    Yes

    Yes

    Yes

    Yes

    Yes

    organization view

    Access to organization detail.

    Yes

    Yes

    Yes

    Yes

    Yes

    packages edit

    Access to package editing.

    -

    -

    -

    -

    -

    roles edit

    Access to admin organization and team roles editing.

    -

    -

    -

    -

    -

    scenario edit

    Access to scenario editing.

    Yes

    Yes

    Yes

    -

    Yes

    scenario logs get

    Access to scenario logs.

    Yes

    Yes

    Yes

    Yes

    Yes

    scenarios get

    Access to the list of all scenarios.

    Yes

    Yes

    Yes

    Yes

    Yes

    scenario verify

    Scenario verification access.

    -

    -

    Yes

    -

    Yes

    scenario view

    Access to scenario detail.

    Yes

    Yes

    Yes

    Yes

    Yes

    template approve

    Can manage approved templates.

    Yes

    -

    -

    -

    -

    template edit

    Access to template editing

    Yes

    Yes

    Yes

    Yes

    Yes

    templates get

    Access to the list of all templates.

    Yes

    Yes

    Yes

    Yes

    Yes

    template view

    Access to template detail.

    Yes

    Yes

    Yes

    Yes

    Yes

    users add

    Can add users.

    -

    -

    -

    -

    -

    users edit

    Access to user editing.

    -

    -

    -

    -

    -

    users get

    Access to the list of all users.

    Yes

    Yes

    Yes

    Yes

    Yes

    webhook logs get

    Access to the webhook logs.

    Yes

    Yes

    -

    -

    Yes

    Admin - system roles

    Scope
    SA
    Admin
    BI

    access

    Access to the admin portal.

    Yes

    Yes

    Yes

    access monitoring

    Access to monitoring.

    Yes

    Yes

    -

    access raw logs

    Access to confidential scenario data.

    Admin - developer roles

    Scope
    D1
    External Developer
    D2 (can't decrypt)
    D3 (restricted)
    D4 (restricted)
    Developer app manager

    Yes

    Yes

    -

    access trackman

    Access to the Trackman Service.

    Yes

    Yes

    -

    admins edit

    Access to admin editing.

    Yes

    Yes

    -

    apps approve

    Can approve apps.

    Yes

    Yes

    -

    apps commit

    Access to commit changes in apps.

    Yes

    Yes

    -

    apps edit

    Access to apps editing.

    Yes

    Yes

    -

    apps get

    Access to apps.

    Yes

    Yes

    -

    apps metadata edit

    Access to apps metadata editing. This permission is child permission of apps edit.

    Yes

    Yes

    -

    decrypt

    Decryption of confidential data.

    Yes

    Yes

    -

    decrypt common

    Decryption of "common data" for packages.

    Yes

    Yes

    -

    exceptions get

    Access to the error database.

    Yes

    Yes

    -

    extras add

    Access to adding extra data and operations.

    Yes

    -

    -

    internal services add

    Can assign internal services.

    Yes

    -

    -

    log as user

    Possibility to log in as a different user.

    Yes

    Yes

    -

    organization edit

    Access to organization editing.

    Yes

    Yes

    -

    organizations get

    Access to the list of all organizations.

    Yes

    Yes

    Yes

    organization view

    Access to organization detail.

    Yes

    Yes

    Yes

    packages edit

    Access to package editing.

    Yes

    Yes

    -

    roles edit

    Access to admin organization and team roles editing.

    Yes

    -

    -

    scenario edit

    Access to scenario editing.

    Yes

    Yes

    -

    scenario logs get

    Access to scenario logs.

    Yes

    Yes

    Yes

    scenarios get

    Access to the list of all scenarios.

    Yes

    Yes

    Yes

    scenario verify

    Scenario verification access.

    Yes

    Yes

    -

    scenario view

    Access to scenario detail.

    Yes

    Yes

    Yes

    template approve

    Can manage approved templates.

    Yes

    -

    -

    template edit

    Access to template editing.

    Yes

    -

    -

    templates get

    Access to the list of all templates.

    Yes

    -

    -

    template view

    Access to template detail.

    Yes

    -

    -

    users add

    Can add users.

    Yes

    Yes

    -

    users edit

    Access to user editing.

    Yes

    Yes

    -

    users get

    Access to the list of all users.

    Yes

    Yes

    Yes

    webhook logs get

    Access to the webhook logs.

    Yes

    Yes

    -

    access monitoring

    Access to monitoring.

    -

    -

    -

    -

    -

    -

    access raw logs

    Access to confidential scenario data.

    Yes

    -

    Yes

    -

    -

    -

    access trackman

    Access to the Trackman Service.

    -

    -

    -

    -

    -

    -

    admins edit

    Access to admin editing.

    Yes

    -

    -

    -

    -

    -

    apps approve

    Can approve apps.

    Yes

    -

    Yes

    -

    -

    Yes

    apps commit

    Access to commit changes in apps.

    Yes

    -

    Yes

    Yes

    -

    Yes

    apps edit

    Access to apps editing.

    Yes

    -

    Yes

    Yes

    -

    Yes

    apps get

    Access to apps.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    apps metadata edit

    Access to apps metadata editing. This permission is child permission of apps edit.

    Yes

    -

    Yes

    -

    -

    Yes

    decrypt

    Decryption of confidential data.

    Yes

    -

    -

    -

    -

    -

    decrypt common

    Decryption of "common data" for packages.

    Yes

    -

    -

    -

    -

    Yes

    exceptions get

    Access to the error database.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    extras add

    Access to adding extra data and operations.

    Yes

    -

    -

    -

    -

    -

    internal services add

    Can assign internal services.

    -

    -

    -

    -

    -

    -

    log as user

    Possibility to log in as a different user.

    Yes

    -

    -

    -

    -

    -

    organization edit

    Access to organization editing.

    -

    -

    -

    -

    -

    -

    organizations get

    Access to the list of all organizations.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    organization view

    Access to organization detail.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    packages edit

    Access to package editing.

    Yes

    -

    Yes

    Yes

    -

    Yes

    roles edit

    Access to admin organization and team roles editing.

    -

    -

    -

    -

    -

    -

    scenario edit

    Access to scenario editing.

    Yes

    -

    Yes

    Yes

    -

    Yes

    scenario logs get

    Access to scenario logs.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    scenarios get

    Access to the list of all scenarios.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    scenario verify

    Scenario verification access.

    Yes

    -

    Yes

    Yes

    -

    Yes

    scenario view

    Access to scenario detail.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    template approve

    Can manage approved templates.

    Yes

    -

    -

    -

    -

    -

    template edit

    Access to template editing.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    templates get

    Access to the list of all templates.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    template view

    Access to template detail.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes

    users add

    Can add users.

    -

    -

    -

    -

    -

    -

    users edit

    Access to user editing.

    -

    -

    -

    -

    -

    -

    users get

    Access to the list of all users.

    Yes

    -

    Yes

    Yes

    -

    Yes

    webhook logs get

    Access to the webhook logs.

    Yes

    Yes

    Yes

    Yes

    -

    Yes

    access

    Access to the admin portal.

    Yes

    Yes

    Yes

    Yes

    Yes

    Yes