Manage SAML2 Authentication

SAML (Security Assertion Mark-up Language) is an umbrella standard that covers federation, identity management and single sign-on (SSO) and single logout (SLO).

Talend Data Catalog supports the SAML 2.0 protocol for external authentication.

SAML authentication requesters and responders communicate by exchanging messages. The mechanism to transport these messages is called a SAML binding. Talend Data Catalog supports the following SAML bindings: HTTP redirect and HTTP POST.

A sample decoded request:

Frequently Asked Questions:

• The value of NameIDPolicy in SAML request is “urn:oasis:names:tc:SAML:2.0:nameid-format:transient”
• The value of Issuer in SAML request is the host name portion of the unique id for the SAML identity provider which you specify in the SAML configuration as the Identity provider
• The assertion consumer service URL is http://<server>:<port>/MM/Auth where server and port are the server and port number where the application server service is running.
• The Service provider (entity id) is the host name where you are running the application server. We use that as the issuers in the SAML requested generated by the application server. Configure the app id and Audience restriction on the ADFS side accordingly.

Set SAML2 Authentication

Steps

1. Sign in as a user with at least theApplication Administratorcapability global role assignment
2. Go to MANAGE > Users in the banner.
3. Select SAML from the Authentication pull-down.

Example

Sign in as Administrator.

Go to Tools > Administration > Users.

Select SAML from the Authentication pull-down.

Configure SAML Authentication

Steps

1. Sign in as a user with at least theApplication Administratorcapability global role assignment
2. Go to MANAGE > Users in the banner.
3. Click Configure Authentication.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the banner.

Select SAML from the Authentication pull-down.

Click Configure Authentication.

Configure the SAML server

In order to enable an external authentication server using the SAML2 protocol, the Administrator needs to configure the SAML server. The following example shows the Configure SAML Server editor parameters.

Steps

The user needs to obtain the following information about the Identity Provider (and Service Provider if the application server is behind a load balancer or proxy server.)

1. IDENTITY PROVIDER X509 CERTIFICATE: The URL of the IdP server
2. X509 CERTIFICATE: the public X509 certificate of the Identity Provider which allows Talend Data Catalog to verify the signatures therefore establish trust in the messages that have been exchanged
3. SINGLE SIGN ON BINDING TYPE: The manner in which SSO binding is accomplished, either by redirect or POST.
4. SINGLE LOGOUT BINDING TYPE: The manner in which SLO binding is accomplished, either by redirect or POST.
5. SINGLE SIGN ON URL: the URL for single sign on.
6. SINGLE LOGOUT URL: the URL for single logout.

7. SAML RESPONSE SIGNATURE ELEMENT: Whether the SAML authentication response message and SAML assertion are digitally signed by the Identity Provider or not.

8. IMPORT IDP METADATA: Allows the application server to read the identity provider’s SAML metadata file which is an XML document that contains information necessary for interaction with the Identity Provider. This document contains the URLs of endpoints, information about supported bindings, identifiers and public keys. After parsing the SAML metadata file, the application server will automatically fill in the other fields from the values specified in the SAML metadata file. The user still needs to configure the Attribute Mappings and Group Mappings to complete the SAML Server configuration.
9. EXPORT SP METADATA: Allows you to export the SAML Server Provider metadata. The application server SP uses the protocol (http or https), server name and the port number that the browser uses to generate the endpoint URLs in the metadata. You may need to customize the SP auto-generated metadata file if it does not work as is.
10. SERVICE PROVIDER ENTITY ID: The host name of the service provider. If the MM application server is behind a loader balancer or proxy server, this should be the host name of the loader balancer or proxy server. We use that as the issuers in the SAML requests generated by the MM application server. Configure the app id and Audience restriction in the IdP server accordingly.
11. ASSERTION CONSUMER SERVICE URL: SAML protocol binding to be used when returning the SAML response from the IdP server if a proxy server or loader balancer is used on the SP side. This is used as the recipient or destination URL of the SAML responses. If the MM application server is behind a loader balancer or proxy server, the protocol, host name, and port in the URL should match those of the loader balancer or proxy server.
12. SERVICE PROVIDER PRIVATE KEY: the private key of the Service Provider. If both Service Provider’s private key and X509 certificate are specified, the SAML authentication requests will be digitally signed by the application server service provider.
13. SERVICE PROVIDER X509 CERTIFICATE: the public X509 certificate of the Service Provider. If both Service Provider’s private key and X509 certificate are specified, the SAML authentication requests will be digitally signed by the application server service provider.

Configuring SAML with Microsoft Active Directory FS.

AD FS is a service provided by Microsoft as a standard role for Windows Server that provides a web login using existing Active Directory credentials. Instructions for configuring and installing AD FS can be found at Microsoft AD FS website.

In your AD FS installation, please note the value for the 'SAML 2.0/W-Federation' URL in the AD FS Endpoints section. If you chose the defaults for the installation, this will be '/adfs/ls/'. Use this value for the Single Sign On URL in configuring the Talend Data Catalog SAML Server.

The Identity Provider should take the value for the ‘Identifier’ URL in the AD FS Relying Party Trusts section.

The SAML server configuration sample parameters look like the following:

Sample decoded response

Here is a sample decoded response in which both response and assertion are signed. We omitted the signatures in the sample. The Attribute statement in the assertion contains the user attributes First Name, Last Name, Login, Email, Full Name and Department. 

In configuring the SAML Server, one can use the following Attribute Mappings corresponding to the attributes received from the SAML response above.

The % matches zero or more characters.

In Okta, the user “Susan Smith” belongs to the groups Everyone and Developers.

After login via the SAML server on Okta, she is now a part of the Producers group:

SAML2 Authentication Workflow

Steps

1. A Client submits an authentication request via the User Interface of a Service Provider
2. To authenticate the Client, the Resource Server constructs a SAML Authentication Request, signs and optionally encrypts it, and sends it directly to the Identity Provider (IdP).
3. The Service Provider redirects the Client’s browser to the IdP for authentication.
4. The IdP verifies the received SAML Authentication Request and if valid, presents a login form for the Client to enter his username and password.
5. Once the Client has successfully logged in, the IdP generates a SAML Assertion (also known as a SAML Token), which includes the Client identity (such as the username entered before) and sends it directly to the Service Provider.
6. The IdP redirects the Client back to the Service Provider
7. The Service Provider verifies the SAML Assertion, extracts the Client identity from it, assigns correct permissions for the Client and then logs him in to the service

Talend Data Catalog does not have the private key of the Identity Provider. Therefore the SAML Assertion received by the Talend Data Catalog can be signed but not encrypted. To validate the signature, Talend Data Catalog only needs the Identity Provider’s public key. However to decrypt the SAML Assertion, Talend Data Catalog would need to have the Identity Provider’s private key. Requiring the Assertion to be signed allows Talend Data Catalog to verify that the assertion contents have not been altered in transit.

Similarly the SAML Authentication Request sent by Meta Integration® Metadata Management (MIMM) can be signed but not encrypted. Talend Data Catalog uses the private key and X.509 certificate of the SP to sign the SAML Authentication Request.

A custom SAML application which Okta Single Sign ON URL is http://mitiauth.com:19980/MM/Auth, is created and configured in Okta. This application can be used as an Identity Provider to demonstrate the SAML authentication workflow. In this case the service at MM.com is the Service Provider, the custom SAML app configured in Okta is the Identity Provider, and the end user is the Client. The SAML server configuration parameters look like the following:

The User Attribute Mapping looks like below:

Steps

Following is the authentication workflow in Talend Data Catalog :

1. An end user clicks on the “Login” button on a metadata management service at Talend Data Catalog .
2. To authenticate the user, Talend Data Catalog generates a SAML Authentication Request and redirects the user to the Okta Single Sign-On URL endpoint with the request embedded. This endpoint is unique for each application within each Okta tenant. Below is the Okta Single Sign-On login window.
3. Once the user is redirected to Okta they’ll need to enter their Okta credentials, unless they had already authenticated into Okta in a previous session within the same browser. In either case, a successful authentication request will send a POST request to the Talend Data Catalog Assertion Consumer Service, i.e. the Talend Data Catalog Authentication Servlet, with an embedded SAML response from Okta. At a minimum, the response will:
   • Indicate that it is indeed from Okta and hasn’t been altered, and contain a digital signature proving such. This signature will be verified by Talend Data Catalog using a public key from Okta that was previously stored in the SAML Server Configuration.
   • Indicate that the user has authenticated successfully into Okta
   • Indicate who the user is via the NameID, a standard attribute used in SAML assertions. Besides the NameID attribute, the response may also contain other attributes specified in the User Attribute Mapping. Talend Data Catalog may retrieve the user information from these attributes..
4. After the assertion is successfully parsed and validated by the Talend Data Catalog Authentication Servlet, the user will then be redirected to the Talend Data Catalog default relay state, e.g., metadata explorer, which is usually the same page they would wind up if they were to simply log in with a username and password.

Go to the Group Assignment tab to auto-assign groups based upon the LDAP security model.

SAML2 single logout workflow

Steps

1. An end user clicks on the “Log out” button on a metadata management service at MM.
2. This MM terminates the MM user session and triggers SP-initiated SLO by sending a logout request to the IDP (Identity Provider)
3. Upon receiving a logout request, the IDP sends a Logout response to the SP that informs the SP whether SLO completed entirely or partially. Note that the IDP may trigger an IDP-initiated SLO to all other SPs that are part of the current session (SAML session) before sending the Logout response to the originating SP. MM currently does not response to the Logout request initiated by IDP.
4. This MM then redirect the user to the “logged out” page.

Signing in with a custom SAML app configured in Okta

A custom SAML application which Okta Single Sign ON URL is http://mitiauth.com:19980/MM/Auth, is created and configured in Okta. This application can be used as an Identity Provider to demonstrate the SAML authentication workflow. In this case the service at MM.com is the Service Provider, the custom SAML app configured in Okta is the Identity Provider, and the end user is the Client. The SAML server configuration parameters look like the following:

The User Attribute Mapping looks like below:

Steps

Following is the authentication workflow in Talend Data Catalog :

1. An end user clicks on the “Login” button on a metadata management service at MM.com.
2. To authenticate the user, Talend Data Catalog generates a SAML Authentication Request and redirects the user to the Okta Single Sign-On URL endpoint with the request embedded. This endpoint is unique for each application within each Okta tenant. Below is the Okta Single Sign-On login window.
3. Once the user is redirected to Okta they’ll need to enter their Okta credentials, unless they had already authenticated into Okta in a previous session within the same browser. In either case, a successful authentication request will send a POST request to the product’s Assertion Consumer Service, i.e. the Talend Data Catalog Authentication Servlet, with an embedded SAML response from Okta. At a minimum, the response will:
   • Indicate that it is indeed from Okta and hasn’t been altered, and contain a digital signature proving such. This signature will be verified by Talend Data Catalog using a public key from Okta that was previously stored in the SAML Server Configuration.
   • Indicate that the user has authenticated successfully into Okta
   • Indicate who the user is via the NameID, a standard attribute used in SAML assertions. Besides the NameID attribute, the response may also contain other attributes specified in the User Attribute Mapping. Talend Data Catalog may retrieve the user information from these attributes..
4. After the assertion is successfully parsed and validated by the this product’s Authentication Servlet, the user will then be redirected to the this product’s default relay state, e.g., MM Explorer, which is usually the same page they’d wind up if they’d simply logged into the Talend Data Catalog with a username and password.