SAML Single Sign-on Configuration Notes

Active Directory Federated Services (ADFS) Notes

These are notes from our test configurations using ADFS as the identity provider. The notes assume that you have ADFS connected to an Active Directory server.

Notes on the Identity Provider Installation/Configuration

• You need an ADFS server with access to an existing Active Directory system (on the same network domain).
• If you need to use the HTTP-Artifact binding, the ADFS server will need to store its configuration and the artifact database in a SQL Server. An existing ADFS server can be converted to use SQL Server.
• Once the ADFS server is installed, the web interfaces of the server (through IIS) should be secured with an SSL certificate. Additionally, MOVEit Transfer will have an SSL certificate protecting its IIS web interface. To support direct requests between the MOVEit Transfer and ADFS servers for direct downloading of metadata files, and artifact resolution requests, each server should be configured to trust the SSL certificate of the other server. This can be done by installing the public portion of each server's SSL certificate on the local computer's Trusted Authority certificate list.

Set up the Service Provider

Configure the MOVEit settings required by ADFS.

• Certificates: SAML requests and responses should generally be signed. OASIS also recommends that encryption be used to enhance security. To support both signing and encryption of SAML messages, create both a Signing Certificate and an Encryption Certificate.
• Assertion consumer interface: By default, MOVEit Transfer enables only the HTTP-Post interface for receiving and consuming SAML assertions from the Identity Provider. If you want to use the HTTP-Artifact interface, enable that interface and move it to the top of the Assertion Consumer Interfaces list.

Register MOVEit as the Service Provider/Relying Party

The SAML Service Provider and Identity Provider must register each other, in order to properly trust the requests and assertions that flow between the two servers. This is typically done by exchanging metadata files, which contain XML descriptions of the services, endpoints, and certificates of the server.

Register MOVEit as a Relying Party in ADFS. You can use the ADFS Management Console to add a Relying Party Trust. This is where you can provide the URL for the Service Provider (MOVEit) metadata file, or provide a copy of the metadata file.

Set User Attributes

The settings for User Attributes are made in the both the Identity Provider's configuration and in the MOVEit settings. These settings determine which user information (such as Account Name, Common Name, Email Address), will be sent to MOVEit Transfer in authentication assertions.

You set the User Attributes, known as "claims" in ADFS, by using the Add Claim Rules dialog (in the ADFS Management Console).

We set the following attributes:

• Add transient session ID claim: These rules required specific settings as described here.

  On the Issuance Transform Rules tab, click the Add Rule button.

  Select Send Claims Using a Custom Rule.

  Enter a rule name like "Create transient session ID"

  Enter the following rule text:

  c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

  && c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant"]

  => add(store = "_OpaqueIdStore",

  types = ("http://example.com/transientsessionid"),

  query = "{0};{1};{2};{3};{4}",

  param = "useEntropy",

  param = c1.Value,

  param = c1.OriginalIssuer,

  param = "",

  param = c2.Value);

  Click Finish to add the rule.

  Click the Add Rule button again.

  Select Transform an Incoming Claim.

  Enter a rule name like "Send transient session ID as NameID".

  As the Incoming claim type, enter: http://example.com/transientsessionid

  Select Name ID as the Outgoing claim type.

  Select Transient Identifier as the Outgoing name ID format.

  Click Finish to add the rule.

• Add Active Directory attributes as claims: You can choose to supply whatever attributes required by your organization, but we set the claims to supply: Windows account name, Common name, Email address, and Group list, as these are the attributes we wanted to use in MOVEit.

In the (MOVEit) Single Signon settings, select to edit the Identity Provider, then in the User Settings, set the following:

• Login name: Windows account name (This is the only required setting.)
• Full name: Common Name
• Email: Email Address

Set other user or group settings as desired.

Register ADFS as the Identity Provider

Now that MOVEit Transfer is registered with the ADFS server, the reverse needs to happen as well. Again, you may either download the ADFS server's metadata (the ADFS server's metadata location is typically "<ADFS Server URL>/FederationMetadata/2007-06/FederationMetadata.xml"), or provide the metadata URL to MOVEit Transfer as part of the Identity Provider configuration.

Test Authentication using SAML

To test the configuration, sign on to MOVEit as an Org admin, copy the Direct User Sign-on Link from the Edit Federated Identity Provider Settings page (for the configured Identity Provider). Sign off from MOVEit, then paste that URL in the Address Bar of your browser. If configured properly, the Identity Provider will authenticate you and then return you to MOVEit Transfer, where you will be signed on. (The Identity Provider may or may not prompt for credentials, depending on the configuration.)

See the Troubleshooting Single Sign-on topic for common configuration issues.

Shibboleth Notes

These are notes from our test configurations using Shibboleth as the identity provider. The notes assume that you have Shibboleth set up as the user store, or connected to an Active Directory server.

Notes on the Identity Provider Installation/Configuration

• Test the Tomcat server used by Shibboleth to make sure it can accept SSL/TLS connections and that it can access the Shibboleth Identity Provider. After installing Shibboleth, to test the Tomcat server, open: C:\Program Files (x86)\Internet2\Shib2IdP\conf\ReadMe.html. The Next Steps section of this document has several links to tests that you can run.
• Verify that the Identity Provider attempts to contact LDAP using TLS. LDAP must be configured to accept SSL/TLS connections. To verify, Go to C:|Program Files (x86)\Internet2\CaptiveTomcat 6.0\conf, then check the setting in attribute-resolver.xml: UseStartTLS should be set to "false". In the same directory, in login.config, the value tls should be set to "false."
• Restart Tomcat6 service.
• To verify that the Identity Provider can contact LDAP\Active Directory, launch the ReadMe.html file and select the Test the IDP Status page here link.
• Once the Shibboleth server is installed, the web interfaces of the server (through IIS) should be secured with an SSL certificate. Additionally, MOVEit Transfer will have an SSL certificate protecting its IIS web interface. To support direct requests between the MOVEit Transfer and Shibboleth servers for direct downloading of metadata files, and artifact resolution requests, each server should be configured to trust the SSL certificate of the other server. This can be done by installing the public portion of each server's SSL certificate on the local computer's Trusted Authority certificate list.

Set up the Service Provider

Configure the MOVEit settings required by Shibboleth.

• Certificates: SAML requests and responses should generally be signed. OASIS also recommends that encryption be used to enhance security. To support both signing and encryption of SAML messages, create both a Signing Certificate and an Encryption Certificate.
• Assertion consumer interface: By default, MOVEit Transfer enables only the HTTP-Post interface for receiving and consuming SAML assertions from the Identity Provider. If you want to use the HTTP-Artifact interface, enable that interface and move it to the top of the Assertion Consumer Interfaces list.

Register MOVEit as the Service Provider/Relying Party

The SAML Service Provider and Identity Provider must register each other, in order to properly trust the requests and assertions that flow between the two servers. This is typically done by exchanging metadata files, which contain XML descriptions of the services, endpoints, and certificates of the server.

• From the Service Provider settings in MOVEit, copy the metadata file (right-click the Service Provider Metadata URL, and save the target as DMZ-Metadata.xml), then copy the file to the Shibboleth system and paste it in the directory: C:\Program Files (x86)\Internet2\Shib2ldp\metadata\ ; then restart the Tomcat6 service on the Shibboleth system.
• On the Shibboleth system, register MOVEit as the Service Provider/Relying Party. To do this, edit the relying-party.xml file, then add the metadata location in the Metadata Configuration section, for example: <metadata:MetadataProvider id="DMZTestOrg" xsi:type="metadata:FileBackedHTTPMetadataProvider" metadataURL=https://<dmz-server>/<org-ID>/SAML/Metadata.xmldisregardSsslCertificate="true"backingFile="C:\Program Files (x86)\Internet2\Shib2ldp\metadata\DMZ-Metadata.xml" />
  Note: Currently, Shibboleth cannot download the Service Provider metadata file from MOVEit Transfer, so it is necessary to copy the file as shown in the first step.

• Also, if you are using the HTTP-Artifact method for the Assertion Consumer Interface (set in MOVEit configuration), then Client Cert Auth needs to be disabled on Shibboleth. To do this: Edit C:\Program Files\Internet2\CaptiveTomcat 6.0\conf\server.xml, and under <Connector port="8443"> change clientAuth="TRUE" to clientAuth="FALSE". Save changes and restart Tomcat.

Set User Attributes

The settings for User Attributes are made in both the Identity Provider's configuration and in the MOVEit settings. These settings determine which user information (such as Account Name, Common Name, Email Address), will be sent to MOVEit Transfer in authentication assertions.

• In Shibboleth, set the User Attributes that will be sent to MOVEit in authentication assertions. To configure the attribute settings, go to C:\Program Files\Internet2\Shib2IdP\conf\ and edit the attribute-resolver.xml file.
• Release the attributes to MOVEit Transfer. To do this, edit the attribute-filter.xml settings.
• Publish the attributes in the Identity Provider's metadata.xml file. To do this, edit the idp-metadata.xml settings.
• In the (MOVEit) Single Signon settings, select to edit the Identity Provider, then in the User Settings, set the following:
  • Login name: Account name (This is the only required setting.)
  • Full name: Common Name
  • Email: Email Address

    Set other user or group settings as desired.

Register Shibboleth as the Identity Provider

Now that MOVEit Transfer is registered with the Shibboleth server, the reverse needs to happen as well. Again, you can either download the Shibboleth server's metadata, or provide the metadata URL to MOVEit Transfer as part of the Identity Provider configuration.

You can either select a local copy of the Identity Provider's metadata file [C:\[folder]\Metadata.xml], or copy the URL from https://<idp-machine>:<port>/idp/shibboleth, then select to add an Identity Provider, then paste the URL into the Identity Provider Metadata URL box.

Test Authentication using SAML

To test the configuration, sign on to MOVEit as an Org admin, copy the Direct User Signon Link from the Edit Federated Identity Provider Settings page (for the configured Identity Provider). Sign off from MOVEit, then paste that URL in the Address Bar of your browser. If configured properly, the Identity Provider will authenticate you and then return you to MOVEit Transfer, where you will be signed on. (The Identity Provider may or may not prompt for credentials, depending on the configuration.)

See the Troubleshooting Single Signon page for common configuration issues.

OneLogin Notes

These are notes from our test configurations using OneLogin as the identity provider. The notes assume that you have OneLogin setup as the user store, or connected to an Active Directory server.

Notes on the Identity Provider Installation/Configuration

• Once the OneLogin server is installed, the web interfaces of the server (through IIS) should be secured with an SSL certificate. Additionally, MOVEit Transfer will have an SSL certificate protecting its IIS web interface. To support direct requests between the MOVEit Transfer and OneLogin servers for direct downloading of metadata files, and artifact resolution requests, each server should be configured to trust the SSL certificate of the other server. This can be done by installing the public portion of each server's SSL certificate on the local computer's Trusted Authority certificate list.

Set up the Service Provider

Configure the Service Provider settings required by OneLogin.

• Certificates: SAML requests and responses should generally be signed. OASIS also recommends that encryption be used to enhance security. To support both signing and encryption of SAML messages, create both a Signing Certificate and an Encryption Certificate.
• Assertion consumer interface: By default, MOVEit Transfer enables only the HTTP-Post interface for receiving and consuming SAML assertions from the Identity Provider. If you want to use the HTTP-Artifact interface, enable that interface and move it to the top of the Assertion Consumer Interfaces list.

Register MOVEit as the Service Provider/Relying Party

The SAML Service Provider and Identity Provider must register each other, in order to properly trust the requests and assertions that flow between the two servers. This is typically done by exchanging metadata files, which contain XML descriptions of the services, endpoints, and certificates of the server.

From the Service Provider settings in MOVEit, open the Service Provider Metadata file and copy the entityID for the MOVEit Transfer organization. Then, open the OneLogin > Configuration page, and paste the entityID into the SAML Audience box.

From the Service Provider settings in MOVEit, copy the URL for the Assertion Consumer Interface, then open the OneLogin > Configuration page, and paste the URL into the SAML Consumer URL and also into the SAML Recipient box.

From the Service Provider settings in MOVEit, copy the URL for the Single Logout Interface (Redirect method), then open the OneLogin > Configuration page, and paste the URL into the SAML Single Logout URL box. For the Single Logout setting, OneLogin currently supports only the Redirect method.

We left the RelayState box empty.

Set User Attributes

The settings for User Attributes are made in the Identity Provider settings in MOVEit and in the OneLogin configuration. These settings determine which user information (such as Account Name, Common Name, Email Address), will be sent to MOVEit Transfer in authentication assertions.

In the (MOVEit) Single Signon settings, select to edit the Identity Provider, then in the User Settings, set the Login name to SAML NameID. This is the only required setting. Set other user or group settings as desired.

In OneLogin, select the Access Control tab and select to use the Default role.

Register OneLogin as the Identity Provider

Now that MOVEit Transfer is registered with the OneLogin server, the reverse needs to happen as well. You need to provide the metadata URL to MOVEit Transfer as part of the Identity Provider configuration.

From the OneLogin Configuration page, copy the Single Signon > Issuer URL, then go to the MOVEit settings, Single Signon, select to add an Identity Provider, then paste the URL into the Identity Provider Metadata URL field.

Test Authentication using SAML

To test the configuration, sign on to MOVEit as an Org admin, then copy the Direct Link URL from your Identity Provider configuration. Sign off from MOVEit, then paste the URL into the Address Bar of your browser. If configured properly, the Identity Provider will authenticate you and then return you to MOVEit Transfer, where you will be signed on. (The Identity Provider may or may not prompt for credentials, depending on the configuration.)

See the Troubleshooting Single Signon page for common configuration issues.