Configure Authentication Providers through ISD UI
Last updated
Was this helpful?
Last updated
Was this helpful?
OpsMx supports Single Sign-on with the authentication providers OpenLDAP, Active Directory and SAML. You can configure these Authentication Providers through ISD UI.
The integration of ISD with these Authentication Providers enables you to log-in your LDAP, Active Directory and SAML users and groups into ISD with their credentials.
This document provides step-by-step instructions to configure Authentication Providers through ISD UI.
ISD Installed
Make sure you have access to your ISD UI.
Account with Authentication Provider
An open and widely accepted application protocol for accessing and managing distributed directory information services over an IP network is the Lightweight Directory Access Protocol (LDAP). LDAP is frequently used to offer a central location to store usernames and passwords. As a result, numerous software programmes and services can connect to the LDAP server to verify users.
Follow the procedure below to configure the OpenLDAP Provider through ISD UI.
Click on "Setup" and then click on "Access Management". The "Access Management" page appears as shown in the image below.
Click on “Authentication”. The list of available Authentication Providers and their respective fields appears. Select the “LDAP” and fill out the information about it that appears on the right pane of the screen and then click the “Save” button. Refer to the images below.
Update the following information on the above screen to configure the OpenLDAP provider:
Vendor: Select the “Other” as LDAP vendor(provider) from the drop-down.
Connection URL: Connection URL to your LDAP server. Once you enter the “Connection URL”, click on the “Test Connection” button. If the URL is valid, it will show the “Successful” message stating “Successfully connected to LDAP.”
Bind Type: Type of the Authentication Method used during LDAP Bind operation. It is used in most of the requests sent to the LDAP server. Currently “none” (Anonymous LDAP Authentication) or “simple”(Bind credential + Bind password Authentication) mechanisms are available. Select “simple” from the drop-down.
Bind DN: DN of LDAP admin which will be used by keycloak to access LDAP server. You need to provide the user tree path who has complete access to the entire LDAP tree.
Bind Credential: Password of LDAP admin. This field is able to obtain its value from the vault and use ${vault.ID} format. Once you enter the password, click on the “Test Authentication” button. If the credentials are valid, it will show the “Successful” message stating “Successfully connected to LDAP”.
User Object Classes: All values of LDAP objectClass attribute for users in LDAP, divided by commas. LDAP user records are found just if they contain all those object classes.
Users DN: Full DN of LDAP tree where your users are. This DN is the parent of LDAP users. It could be for example 'ou=users,dc=example,dc=com' assuming that your typical user will have DN like 'uid='john',ou=users,dc=example,dc=com
In addition to the above parameters in “User Search Settings” if you wish, you can try the following advanced options.
Edit Mode: The mode of communication between ISD and LDAP. This is always READ_ONLY.
Username LDAP attribute: Name of the LDAP attribute, which is mapped as ISD username. For many LDAP server vendors it can be 'uid'. The attribute should be filled for all LDAP user records you want to import from LDAP.
RDN LDAP attribute: Name of the LDAP attribute, which is used as RDN (top attribute) of typical user DN. Usually it's the same as the Username LDAP attribute, however it is not required.
UUID LDAP attribute: Name of the LDAP attribute, which is used as a unique object identifier (UUID) for objects in LDAP. For many LDAP server vendors, it is 'entryUUID'; however some are different. For example, for Active Directory it should be 'objectGUID'. If your LDAP server does not support the notion of UUID, you can use any other attribute that is supposed to be unique among LDAP users in the tree. For example 'uid' or 'entryDN'.
Group DN: LDAP DN where groups of this tree are saved. For example 'ou=groups,dc=example,dc=org'
Group Search Filter: Name of LDAP attribute on group, which is used for membership mappings. Usually it will be 'member' .However when 'Membership Attribute Type' is 'UID' then 'Membership LDAP Attribute' could be typically 'memberUid'.
Group Role Name Attribute: Name of LDAP attribute, which is used in group objects for name and RDN of group. Usually it will be 'cn' . In this case typical group/role object may have DN like 'cn=Group1,ou=groups,dc=example,dc=org'
In addition to the above parameters in “Group Search Settings” if you wish, you can try the following advanced options.
Group Object Classes: Object class (or classes) of the group object. It is divided by comma if more classes are needed. In typical LDAP deployment it could be 'groupOfNames'.
Membership User LDAP Attribute: Used just if Membership Attribute Type is UID. It is the name of LDAP attribute on user, which is used for membership mappings. Usually it will be 'uid' . For example if the value of 'Membership User LDAP Attribute' is 'uid' and LDAP group has 'memberUid: john', then it is expected that particular LDAP user will have attribute 'uid: john'.
Membership Attribute Type:
DN means that LDAP group has its members declared in the form of their full DN. For example, 'member: uid=john,ou=users,dc=example,dc=com' .
UID means that the LDAP group has its members declared in the form of pure user uids. For example 'memberUid: john'.
Mode:
LDAP_ONLY means that all group mappings of users are retrieved from LDAP and saved into LDAP.
READ_ONLY is Read-only LDAP mode where group mappings are retrieved from both LDAP and DB and merged together. New group joins are not saved to LDAP but to DB.
IMPORT is Read-only LDAP mode where group mappings are retrieved from LDAP just at the time when a user is imported from LDAP and then they are saved to local ISD DB.
User Groups Retrieve Strategy: Specify how to retrieve groups of user.
LOAD_GROUPS_BY_MEMBER_ATTRIBUTE means that roles of user will be retrieved by sending LDAP query to retrieve all groups where 'member' is our user.
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE means that groups of user will be retrieved from 'memberOf' attribute of our user. Or from the other attribute specified by 'Member-Of LDAP Attribute'.
Member-Of LDAP Attribute:
After filling the data fields with the necessary information in the above screen, Turn ON the “Enabled” button and then click the “Save” button.
Now you are done with enabling LDAP as an authentication provider. Any of the users who belong to your user group in LDAP can access the ISD UI by logging-in with their credentials.
The application protocol LDAP is used to interact with different directory services. Passwords and other security data are stored in directory services like Active Directory, along with user and account information. The information can then be shared with other networked devices. LDAP can be used by enterprise applications to authenticate, access, and find data.
Follow the procedure below to configure the Active Directory Provider through ISD UI.
Click on "Setup" and then click on "Access Management". The "Access Management" page appears as shown in the image below.
Click on “Authentication”. The list of available Authentication Providers and their respective fields appears. Select the “LDAP” and fill out the information about it that appears on the right pane of the screen and then click the “Save” button. Refer to the images below.
Update the following information on the above screen to configure the “Active Directory” provider:
Vendor: Select the “Active Directory” as LDAP provider from the drop-down.
Connection URL: LDAP Provider URL to your LDAP server. Once you enter the “Connection URL”, click on the “Test Connection” button. If the URL is valid, it will show the “Successful” message stating “Successfully connected to LDAP.”
Bind Type: Type of the Authentication Method used during LDAP Bind operation. It is used in most of the requests sent to the LDAP server. Currently “none” (Anonymous LDAP Authentication) or “simple”(Bind credential + Bind password Authentication) mechanisms are available. Select “simple” from the drop-down.
Bind DN: DN of LDAP admin which will be used by keycloak to access LDAP server. You need to provide the user tree path who has complete access to the entire LDAP tree.
Bind Credential: Password of LDAP admin. This field is able to obtain its value from the vault and use ${vault.ID} format. Once you enter the password, click on the “Test Authentication” button. If the credentials are valid, it will show the “Successful” message stating “Successfully connected to LDAP”.
User Object Classes: All values of LDAP objectClass attribute for users in LDAP, divided by commas. LDAP user records are found just if they contain all those object classes.
Users DN: Full DN of LDAP tree where your users are. This DN is the parent of LDAP users. It could be for example 'ou=users,dc=example,dc=com' assuming that your typical user will have DN like 'uid='john',ou=users,dc=example,dc=com
In addition to the above parameters in “User Search Settings” if you wish, you can try the following advanced options.
Edit Mode: The mode of communication between ISD and LDAP. This is always READ_ONLY.
Username LDAP attribute: Name of the LDAP attribute, which is mapped as ISD username. For many LDAP server vendors it can be 'uid'. For Active Directory it can be 'sAMAccountName' or 'cn'. The attribute should be filled for all LDAP user records you want to import from LDAP.
RDN LDAP attribute: Name of the LDAP attribute, which is used as RDN (top attribute) of typical user DN. Usually it's the same as the Username LDAP attribute, however it is not required. For example, for Active Directory, it is common to use 'cn' as RDN attribute when the username attribute might be 'sAMAccountName'.
UUID LDAP attribute: Name of the LDAP attribute, which is used as a unique object identifier (UUID) for objects in LDAP. For many LDAP server vendors, it is 'entryUUID'; however some are different. For example, for Active Directory it should be 'objectGUID'. If your LDAP server does not support the notion of UUID, you can use any other attribute that is supposed to be unique among LDAP users in the tree. For example 'uid' or 'entryDN'.
Group DN: LDAP DN where groups of this tree are saved. For example 'ou=groups,dc=example,dc=org'
Group Search Filter: Name of LDAP attribute on group, which is used for membership mappings. Usually it will be 'member' .However when 'Membership Attribute Type' is 'UID' then 'Membership LDAP Attribute' could be typically 'memberUid'.
Groupe Role Name Attribute: Name of LDAP attribute, which is used in group objects for name and RDN of group. Usually it will be 'cn' . In this case typical group/role object may have DN like 'cn=Group1,ou=groups,dc=example,dc=org'
In addition to the above parameters in “Group Search Settings” if you wish, you can try the following advanced options.
Group Object Classes: Object class (or classes) of the group object. It is divided by comma if more classes are needed. In typical LDAP deployment it could be 'groupOfNames'. In Active Directory it's usually 'group'.
Membership User LDAP Attribute: Used just if Membership Attribute Type is UID. It is the name of LDAP attribute on user, which is used for membership mappings. Usually it will be 'uid' . For example if the value of 'Membership User LDAP Attribute' is 'uid' and LDAP group has 'memberUid: john', then it is expected that particular LDAP user will have attribute 'uid: john'.
Membership Attribute Type:
DN means that LDAP group has its members declared in the form of their full DN. For example, 'member: uid=john,ou=users,dc=example,dc=com' .
UID means that the LDAP group has its members declared in the form of pure user uids. For example 'memberUid: john'.
Mode:
LDAP_ONLY means that all group mappings of users are retrieved from LDAP and saved into LDAP.
READ_ONLY is Read-only LDAP mode where group mappings are retrieved from both LDAP and DB and merged together. New group joins are not saved to LDAP but to DB.
IMPORT is Read-only LDAP mode where group mappings are retrieved from LDAP just at the time when a user is imported from LDAP and then they are saved to local ISD DB.
User Groups Retrieve Strategy: Specify how to retrieve groups of user.
LOAD_GROUPS_BY_MEMBER_ATTRIBUTE means that roles of user will be retrieved by sending LDAP query to retrieve all groups where 'member' is our user.
GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE means that groups of user will be retrieved from 'memberOf' attribute of our user. Or from the other attribute specified by 'Member-Of LDAP Attribute'.
Member-Of LDAP Attribute:
After filling the data fields with the necessary information in the above screen, Turn ON the “Enabled” button and then click the “Save” button.
Now you are done with enabling Active Directory as an authentication provider. Any of the users who belong to your user group in Active Directory can access the ISD UI by logging-in with their credentials.
Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization information between parties such as identity provider and a service provider.
Following are the sequence of activities to configure the SAML Provider through ISD UI.
Follow the procedure below to create an application integration in okta.
After you login into Okta, click on “Applications” under Applications in the left side navigation pane and then click on the “Create App Integration” button. Refer to the image below.
Now the “Create a new app integration” screen appears. Select “SAML 2.0” and click the “Next” button. Refer to the image below.
Provide a name to the app and click the “Next” button. Refer to the image below.
Now the “SAML Settings” screen appears under the “Configure SAML” page as shown below.
Update the following information on the above screen:
Single sign-on URL: The Redirect URL from the “SAML Provider” page in ISD UI. Go to “Setup” → “Access Management”→ “Authentication” → SAML in the ISD UI and copy the Redirect URL and paste here. Refer to the image below.
Audience URL (SP Entity ID): The Service Provider Entity ID from the “SAML Provider” page in ISD UI. Go to “Setup” → “Access Management”→ “Authentication” → SAML in the ISD UI and copy the Service Provider Entity ID and paste here. Refer to the image below.
Name ID format: Select the “EmailAddress” from the drop-down.
Application Username: Select the “Email” from the drop-down.
Update application username on: Select the “Create and update” from the drop-down.
In the same “Configure SAML” page, further scroll-down to the “Group Attribute Statements” screen as shown below.
Update the following information on the above screen and click the “Next” button.
Name: Give the name as “memberOf”
Filter: Select “Matches regex” from the drop-down and enter “.*” in the empty data field next to the dropdown.
Now the “Feedback” page appears. Select the “I’m a software vendor, I’d like to integrate my app with Okta” in the Feedback page and click the “Finish” button. Refer to the image below.
Click on the “View SAML setup instructions” under “SAML Setup” as shown below.
Once you click on the “View SAML setup instructions”, the following screen appears. Scroll-down to “Optional”. You will find the IDP metadata under “Optional”. Copy the entire metadata and save it as a file in XML format. This file is required when you are configuring the SAML provider in ISD UI.
Follow the steps below to configure the SAML Provider through ISD UI.
Click on "Setup" and then click on "Access Management". The "Access Management" page appears as shown in the image below.
Click on “Authentication”. The list of available Authentication Providers and their respective fields appears. Select the “SAML” and fill out the information about it that appears on the right pane of the screen and then click the “Save” button. Refer to the images below.
Update the following information on the above screen to configure the SAML provider:
Redirect URL: The redirect URL to use when configuring the identity provider.
Click on the “Choose File” button under “Import from file” to import the metadata file from the location where you have saved it.
Service Provider Entity ID: The Entity ID that will be used by your IDP to uniquely identify this SAML Service Provider (ISD).
Single Sign-On Service URL: The URL that must be used to send authentication requests (SAML AuthnRequest).
Group Attribute: The group attribute helps ISD to identify the groups the user belongs to. You can add group attribute statements to the SAML assertion shared with ISD from your Identity Provider. The value entered here should match the name of the group attribute on your IDP. By default it is “memberOf”.
After filling the data fields with the necessary information in the above screen, Turn ON the “Enabled” button and then click the “Save” button.
Now you are done with enabling SAML as an authentication provider. Any of the users who belong to your user group in SAML can access the ISD UI by logging-in with their credentials.
Identity Provider Metadata: Import the metadata file downloaded from your Identity Provider. For detailed information on how to download the metadata and create a file, Refer .
