FlexDeploy can be integrated with a single sign-on service using various options like OpenID Connect, SAML, OAuth etc. You can use an external service like Okta, Microsoft Azure AD, and many more, or use existing corporate single sign-on solution. Note that FlexDeploy does not provide single sign-on and multi-factor authentication services.
Integration mechanisms supported are OpenID Connect, SAML, OAuth. We have verified this using Okta and Microsoft Azure AD using OpenID Connect. For other OpenID Connect providers and other types of integrations, please reach out to us using the support portal.
A FlexDeploy user record will still be created when users from your single sign-on service performs login for the first time. See New User Process on the Realms page.
Important points about this integration:
The REST API still requires logging in using local realm users, or API Tokens. API Tokens can be created for single sign-on users.
Once you enable single sign-on, you will not be able to configure or use LDAP Realms for authentication and authorization. You can still login using local users, which can be useful if there are issues with single sign-on provider.
You can further secure this by enabling multi-factor authentication, where users are granted access only after successfully presenting two or more pieces of evidence to an authentication mechanism. This will not be discussed here as it will be done on your single sign-on provider.
Even after enabling single sign-on, you will be able to log in using local users if necessary. If you want to log in with local users, then navigate directly to https://FLEXDEPLOYHOST:FLEXDEPLOYPORT/flexdeploy/next/#/login.
Previously single sign-on was configured using configuration file. Customers using single sign-on using configuration file with previous versions of FlexDeploy will automatically be migrated to SSO Realm.
If an SSO Realm is enabled, no LDAP realms are allowed and users are directed to login with single sign-on provider instead of through the normal FlexDeploy login page.
If there is an issue logging in with SSO, or you want to login as an internal user such as fdadmin, go to the page flexdeploy/next/#/login.
Configuring an SSO Realm
If you had an fdsso.config file setup previously, it will automatically be upgraded to an SSO Realm. Starting with FlexDeploy 7.0, SSO Realms are seen in the UI. The file is no longer needed after the first startup of 7.0+.
Only FlexDeploy Administrators can update Realm settings.
In order to enable or disable single sign-on, use Enable Single Sign-On switch.
When you enable single sign-on, a new SSO realm will be populated with a sample configuration, and you will definitely need to configure it to your needs. You can also delete all details (see General section below), and press CTRL+Space to choose another sample.
It’s OK if the provider isn’t the same as yours, but choose either SAML or OIDC correctly.
Other providers are fine to use!
You can make credentials for any sensitive values and include them in the script. Reference them by using the syntax ${{CREDENTIAL NAME}}. Variable name suggestions will show up after typing ${{.
Here are some pages of information about some identity providers that we have tested more thoroughly and documented.
Group Mapping with SSO Realm
Group Mapping is now available for SSO Realm. This guide will show you what to do in FlexDeploy to enable it. If you are using OIDC, you will also need to add a scope setting.
The line oidcConfig.scope = openid,groups,profile,email needs to be added on the general tab if it isn’t there.
When you edit your SSO realm, you will find a tab for Group Mapping.
Area | Description | |
|---|---|---|
1 | Enable Group Mapping | This should be enabled if you want to associate the SSO groups assigned to a user to FlexDeploy groups. Changing this flag will require a restart of FlexDeploy. |
2 | Group Attribute Name | When logging in via SSO, a user profile object is returned from the SSO provider that often includes things like username, display name, email etc. This also typically includes a field for the SSO groups the user belongs to. The name of that group/role field should be specified here. If the field is named Microsoft Azure or Okta Both Microsoft Azure and Okta return Other providersIf you don’t know what to put, you will need to set the org.pac4j logging to FINEST and login with an SSO user. This should log the user profile object and you can inspect to find the groups or roles field. Search for a line starting with the text Then set the logging back to info and look for the groups in the logs. If you can’t find them, share the logs with the FlexDeploy support team. |
3 | Group Mapping | In this location is where SSO groups will be mapped to FlexDeploy groups. Unlike LDAP group mapping, the available SSO groups are not displayed and instead must be manually entered. What to enterWhether to specify group names, ids, or some other identifier depends upon what is returned in the SSO user profile group field (see group attribute name above) See below for a more detailed explanation of group mapping |
Group Mapping
Area | Description | |
|---|---|---|
1 | FlexDeploy Groups | Here you can select the FlexDeploy group that you would like SSO groups “mapped to”. For example, if you want the SSO group |
2 | Mapped SSO Groups | Each mapped SSO group will show up as a row in the list on the right. You can remove the mapping by clicking the X button. |
3, 4 | Available SSO Groups | Previously mapped SSO groups will show up in this dropdown. Here you can select one to add a new mapping. |
5 | Add new SSO Group | If your SSO group is not visible in the dropdown you can add a new group by clicking the + ADD GROUP button. If you are unsure what to specify for the group see the Group Mapping field in the table above. |