Configuring Single Sign-On for ActiveTransfer Web Client

ActiveTransfer supports Single Sign-On (SSO) through Security Assertion Markup Language (SAML) 2.0, an XML-based framework for the exchange of security information. You can use SAML to access ActiveTransfer web client through SSO. SSO is supported only for HTTPS protocol.

ActiveTransfer serves as the service provider (SP) and communicates between a third-party identity provider (IDP) such as, ADFS, Okta, and so on, to access the target application, ActiveTransfer web client. You can configure ActiveTransfer for exchanging authentication data between the third-party identity provider and ActiveTransfer service provider. The third-party identity provider is the SAML authority and ActiveTransfer is the SAML consumer.

Who are involved?

ActiveTransfer administrator, who performs SSO configurations in ActiveTransfer.

Identity provider administrator, who creates an identity provider account and manages the SSO configurations for ActiveTransfer.

ActiveTransfer web client users, who use the ActiveTransfer web client to perform file transfers.

Visual Model

Preconditions

User with SSO credentials

Third-party SAML identity provider such as OKTA

User credentials set up on third party SAML identity provider

ActiveTransfer Server installed with SAML configuration

Redirection URI, which is the URL generated or shared by the identity provider to access the ActiveTransfer web client

Users defined in My webMethods Server must be associated with ActiveTransfer Server for SSO authorization

Basic Flow

To configure SSO in ActiveTransfer

1. Log on to ActiveTransfer Server.

a. On the Listeners page, select an HTTPS listener for which you want to enable SSO.

b. Under Bindings, select the Support single sign-on option.

The HTTP host name and port (for example, https://localhost:234) is now enabled for SSO. This is the endpoint URL for access to ActiveTransfer web client. This URL is used to configure the ActiveTransfer web client in the identity provider as a service provider or an application.

2. Configure the system property mft.server.https.auth.saml to true in the Integration Server_directory \instances\ instance_name \packages\WmMFT\config\properties.cnf file.

3. Configure the redirection URI in the mft.server.https.auth.saml.redirecturi property.

For example, https://idp.machine/adfs/ls/idpinitiatedsignon.aspx.

4. In the Security Infrastructure (SIN) module, configure the profiles for SAML in the configuration file com.softwareag.sso.pid.properties that is located in the Software AG_directory/profiles/profile/configuration/com.softwareag.platform.config.propsloader directory.

The default configuration is:

com.softwareag.security.idp.truststore.location=/common/conf/
platform_truststore.jks
com.softwareag.security.idp.truststore.password=manage
com.softwareag.security.idp.truststore.keyalias=ssos
com.softwareag.security.idp.truststore.type=JKS

Note:
SIN searches for com.softwareag.security.idp.truststore.keyalias to load the alias. If a user wants to configure more than one alias, then do not set any value to this property.

How Does SSO Work When The User Accesses ActiveTransfer Web Client?

1. For the first-time login, the user types the ActiveTransfer web client URL (for example, https://localhost:234) in a web browser.

The first-time logins are preauthenticated by the browser and redirected to the identity provider for login. The SAML identity window appears.

2. The user types the user name and password.

3. An SSO token is sent through the HTTPS port to the identity provider and results in one of the following:

The SAML configuration is authenticated successfully.

ActiveTransfer web client is displayed. The user can switch between the applications without having to log in again.

The SAML configuration is not authenticated successfully and the user authentication fails. In the next login, the user can do one of the following:

Bypass SSO login to the HTTPS port by appending nosso at the end of the URL. For example, https://servername:port/nosso.