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.

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 groups or roles you do not need to specify this field as those will automatically be checked.

Microsoft Azure or Okta

Both Microsoft Azure and Okta return groups or roles. As such, you can omit this field if you are using one of those SSO providers.

Other providers

If 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 org.pac4j.core.client.BaseClient.retrieveUserProfile

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 enter

Whether 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 `admins` to map to the FlexDeploy group `FD Administrators`, you should select `FD Administrators` here.
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.