Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
Go to Administration > System Settings.
Select Enabled from the Two Factor Authentication menu.
For Two Factor Authentication app name (visible in Google Authenticator) enter the name you want to appear in the authentication app.
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.
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:
Log in to Okta and go to Admin > Applications > Applications.
Click Create app integration and select SAML 2.0.
Name your app and upload your icon.
Click Next.
Configure the following SAML settings including:
Click Show advanced settings and enter the following:
Enter the following attributes and click Next.
In the Are you a customer or partner? field, select I'm an Okta customer adding an internal app.
In the App type field, select This is an internal app that we have created
Click Finish.
Go to Admin > Applications > Applications and select your SAML SSO app. to access the necessary information.
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
Unspecified
user.email
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.
Log in to your Make White Label instance.
Go to Administration > System settings.
Select an SSO type.
None - default option indicating that SSO is turned off.
OAuth 2.0
Select this option for OpenID Connect (OIDC).
Fill in the protocol-specific information as described in the tables following this procedure.
Enter an IML resolve. The IML resolve maps necessary data such as ID, name, and email, between Make and your identity provider.
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.
Click Save.
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.
The following fields appear once you select OAuth 2.0 from the SSO menu:
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
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
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:
In the following example, the resolve maps the following values:
Service provider certificate and private key that you create
This configuration supports the following:
Service provider initiated SSO
Single Log Out [optional]
Once you configure SSO, your end-users don't use the default sign-in form. Instead, they use the dedicated SSO sign-in options.
Go to your login URL.
Click Sign in with SSO.
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.
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:
Go to Administration > System settings.
Scroll down to SSO Type.
Under SSO type, select SAML 2.0.
Create your service provider primary key and certificate:
Use openssl or similar. Mac users can use Terminal
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.
Go to the login page for your instance. Log out if needed.
Click Sign in with SSO.
Log in using your Okta credentials and consent to Make's access to your user data.
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.
{
"email":"{{get(user.attributes.email, 1)}}",
"name":"{{get(user.attributes.firstName, 1)}} {{get(user.attributes.last}}
"id":"{{user.name_id}}"
}Microsoft Azure supports both OAuth 2.0 and SAML 2. Perform the following steps to connect Make with Azure Active Directory.
Log in to your Azure Portal and open Azure Active Directory.
Open App registrations and click New registration.
Give the registration a name.
Fill in the Redirect URL.
Find the Redirect URL In Make > Organization > Settings after you select an SSO type.
Click Register.
Note down the Application (client) ID.
Paste this ID into your Make settings.
Go to Certificates and secrets and click New client secret.
Paste the secret value into your Make settings.
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.
Paste the following into the User information URL in Make settings.
In Make, set up Login scopes and Scopes separator:
Login scopes: openid, profile, email
Scopes separator: space
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}}"}
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.
Go to Organization > SSO.
Enter the following information from Okta into the IdP login URL and Identity provider certificate fields.
In the Allow unencrypted assertions, select Yes.
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}}"}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
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
access
Access to the admin portal.
Yes
Yes
Yes
access monitoring
Access to monitoring.
Yes
Yes
-
access raw logs
Access to confidential scenario data.
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