...
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.
There are some limitations in the current version of this integration:
...
Group mapping (Claim in OpenID Connect) is not yet supported. You will need to configure authorization for users using FlexDeploy UI.
A FlexDeploy user record will still be created when users from your single sign-on service 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, alternatively you can use or API Tokens. Configuration is done using configuration files. There is no UI available at this time.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 other 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.
| Info |
|---|
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. |
| Include Page |
|---|
You can enable SSO, MFA, or both as it depends on your Provider.
| Table of Contents | ||||
|---|---|---|---|---|
|
Enable Single Sign-On and/or Multi Factor Authentication
Single sign-on integration will be done by adding a configuration file on the FlexDeploy application server host. You should keep this file readable only by the FlexDeploy process user. There is no restriction on where this file should be kept, but it’s a good idea to keep it with the FlexDeploy installation files, For example, $FLEXDEPLOY_HOME/.sso folder. If you change values in this file, you will need to restart your FlexDeploy server to pick up those changes. Make sure permissions on this folder are 700, so as to not allow other users to read this file.
The configuration file can be named as per your wish, but we will use the name fdsso.config for this documentation. The location of the configuration file will need to be added to server startup arguments in setenvoverride.sh file or setenvoverride.bat file. We recommend that this fdsso.config file is not kept under apache-tomcat-flexdeploy folder, as that folder is replaced during upgrade process. Here is the syntax for startup argument:
| Code Block | ||
|---|---|---|
| ||
-Dflexagon.fd.sso.config=FULLY_QUALIFIED_PATH_TO_SSO_CONFIG_FILE |
Here are some examples of fdsso.config files for various providers.
|