_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 1

Informatica Cloud

Single Sign On

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 2

1 Introduction Single Sign On (SSO) to Informatica Cloud Service(ICS) is based on SAML’s “Web Browser SSO Profile”. ICS acts as the Service Provider (SP). ICS customers leveraging Single Sign On will configure a SAML 2.0 compliant Identity Provider (IDP) that ICS may delegate authentication to. The web user authenticates (or has already authenticated) to the IDP, which then produces an authentication assertion and ICS consumes the assertion to establish a security context in ICS for the web user. It is assumed that the user is using a standard commercial browser and can authenticate to the identity provider.

2 What does Informatica Cloud offer as part of SAML based SSO?

Informatica Cloud Service (ICS) offers the following as part of SAML based SSO addition.

Lets customers configure their SAML IDP settings in ICS and also copy ICS SAML metadata for

use in customer's IDP. The configuration includes things like IDP URLs, mapping of SAML user-

attributes, roles to ICS user-fields, roles etc.

Lets users of SAML Org to access a customized version (specific to their org) of ICS login URL to

initiate SAML SSO request. ICS would then send SAML authentication request to the SAML Org's

IDP.

(ICS) Exposes SAML Assertion Consumer Service (aka ACS, an ICS URL) which can process SAML

authentication response from the org's SAML IDP. Once ICS receives the SAML authentication

response from the org's IDP, ICS will establish user-session and logs-in the user into ICS.

Lets logged-in SSO user to logout from ICS. Once the user clicks on logout link in ICS (or his/her

session times-out), ICS will send a SAML logout request to IDP so that IDP can terminate the

user-session at IDP-side.

An ICS Org that is using SAML based SSO has the option to create some users in ICS (in addition

to the first Admin user created as part of registering for a new ICS account) for the purpose of

registering Secure Agent, for using ICS REST-API and for Migrate Objects. These users will use

the common ICS login URL and login using ICS username/password.

3 What do customers need to be able to use SAML based SSO to ICS?

For customers/prospects of ICS to be able to use SAML based SSO, they need the following:

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 3

A customer should have SAML 2 based Identity Provider. As part of this, their IDP would be using

a public certificate (issued by certificate authority). Examples of common IDPs : ADFS, Okta,

SSOCircle, OpenLDAP, Shibboleth

Have an ICS Org and Org administrator access (and licenses) to setup SSO

Login to ICS and configure SAML IDP settings in ICS. Then copy ICS SAML metadata and hand-

over to SAML IDP administrator. Also copy the ICS SSO URL.

SAML SSO users can login to ICS in two ways:

Enter their org's ICS SSO URL in browser. (This is called Service Provider initiated SSO).

Optional - needs configuration on Org's IDP side: Click on a link in their company's

intranet which would take them to their SAML IDP which after establishing IDP user-

session will send SAML authentication response (SAML Assertion) to ICS. (This is called

IDP initiated SSO).

4 Definition of Terms INFA - Informatica ICS – Informatica Cloud Services SAML – Security Assertion Markup Language OASIS - Organization for the Advancement of Structured Information Standards ACS - Assertion Consumer Service IDP - Identity Provider SP - Service Provider SSO - Single Sign-on SLO – Single Log Out ADFS – Microsoft Active Directory Federation Services ECP – SAML Enhanced Client or Proxy profile. PAOS – Reverse SOAP Org – Organization Org ID – Organization ID Customer – Informatica Cloud Customer SFDC – Salesforce.com ICS Ops – Informatica Cloud Operations Agent or Secure Agent – Informatica Cloud Secure Agent

5 Scope of document

The scope of this document is limited to describing ICS as SAML 2.0 Service Provider.

6 References

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 4

SAML Executive Overview: https://www.oasis-open.org/committees/download.php/13525 SAML Technical Overview: https://www.oasis-open.org/committees/download.php/27819/ SAML Glossary: http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf SAML Profiles: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Assertions & Protocols: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Authentication Context: http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf SAML Bindings: http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf SAML Metadata: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf

7 SAML Terminology SAML Binding, Protocol Binding: Generically, a specification of the mapping of some given protocol's messages, and perhaps message

exchange patterns, onto another protocol, in a concrete fashion. For example, the mapping of the SAML

<AuthnRequest> message onto HTTP is one example of a binding. The mapping of that same SAML

message onto SOAP is another binding. In the SAML context, each binding is given a name in the pattern

“SAML xxx binding”.

SAML Assertion: A piece of data produced by a SAML authority regarding either an act of authentication performed on a

subject, attribute information about the subject, or authorization data applying to the subject with

respect to a specified resource.

SAML Profile: A set of rules for one of several purposes; each set is given a name in the pattern “xxx profile of SAML”

or “xxx SAML profile”.

Rules for how to embed assertions into and extract them from a protocol or other context of

use.

Rules for using SAML protocol messages in a particular context of use.

Rules for mapping attributes expressed in SAML to another attribute representation system.

Such a set of rules is known as an “attribute profile”.

8 Overview of SAML SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information

about a principal (usually an end user) between a SAML authority, that is an identity provider, and a

SAML consumer, that is a service provider.

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 5

9 Single Sign-On (SSO) SSO to ICS is based on SAML’s “Web Browser SSO Profile”. A web user either accesses a resource at ICS

(SP), or accesses their organization’s IDP such that the SP (ICS in this case) and desired resource are

understood or implicit. The web user authenticates (or has already authenticated) to the IDP, which

then produces an authentication assertion (possibly with input from ICS) and ICS consumes the assertion

to establish a security context in ICS for the web user.

It is assumed that the user is using a standard commercial browser and can authenticate to the identity

provider by some means outside the scope of SAML.

10 Non-Browser Client Authentication SAML Authentication from clients other than Web-Browser is handled differently than SAML based

authentication (SSO) from Web-Browser.

11 Configure SAML IDP & Generate ICS SAML Metadata

For ICS to be able to send authentication request to the Org's SAML IDP, ICS needs to have required IDP metadata like URL of IDP SSO Service, and if the authentication response from IDP was signed by IDP, ICS needs to know IDP's certificate so that it can validate the signature. Similarly, ICS needs to know whether the Name Identifier (login id) in IDP is user's email address or something else.

Org Admin can configure all this "SAML IDP Configuration" metadata in a new Administration page. This page will also let Org Admins to map their user-attributes (First Name, Last Name, Email Address etc.) and user-roles to their corresponding ICS user-fields and roles. Only if an org has "SAML based Single Sign-On" license, this page will be displayed.

Unless IDP is not configured in ICS, SSO users of that Org cannot use SAML SSO to login to ICS.

When saving the SAML IDP configuration for the first time, we will generate a 10-character unique random token (and save it to ICS repository) which will be used in SAML SSO URLs instead of Org ID.

Based on the IDP settings, ICS will generate ICS SAML metadata (specific to the Org) which has to be used in the IDP.

Identity Provider Configuration: IDP metadata can be specified by either uploading IDP metadata XML file or by manually entering. If metadata xml file is uploaded, ICS can parse and extract most of IDP configuration with the exception of Logout Page URL and sometimes Name ID format.

o Issuer URL: The Issuer value in all messages from IDP to ICS should match this value (<saml:Issuer>http://idp.example.com</saml:Issuer>). In most of the cases, this will be the SAML Entity ID of the IDP.

o Single Sign-On Service URL: ICS will send the authentication request to this URL with SAMLRequest parameter. For Web-Browser based SSO, ICS would let/require customers to specify IDP’s HTTP-POST SAML binding URL for SingleSignOnService.

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 6

o Name Identifier Format: The IDP might support different Name ID Formats, but ICS has to specify the format of the Name Identifier (in the authentication request) that must be returned by IDP to ICS for all SP-initiated SSO. For example, if ICS needs email address as the Name ID, then Name ID Format is “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”. The Name Identifier value returned by IDP in the Assertion (in response to authentication request) will be used as the ICS login name (username). Note on Name ID Limitation: Name ID cannot be a transient value which could be different for each login (or authentication response or <Assertion>). For a given user/principal, each SSO into ICS (via SAML assertion from IDP) should contain the same Name ID value.

o Single Logout Service URL: When the SSO authenticated ICS user clicks on logout link in ICS (or his/her ICS browser session expires), ICS will send a logout request to this URL at IDP. ICS would require customers to specify IDP’s HTTP-POST SAML binding URL for SingleLogoutService for all Web-Browser based logouts.

o Signing Key: ICS will use IDP’s Signing (Public) Key to validate digital XML signature of IDP responses. This must be a Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----".

o Use Signing key for encryption flag: This flag should be turned-ON (checked) indicating signing key is used for encrypting as well.

o Encryption Key: ICS will use IDP’s Encryption (Public) Key to encrypt Logout requests. This must be a Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----".

o Logout Page URL: URL where user will be forwarded (redirected) after successful logout from ICS Web-Browser. If this is not specified, then user will redirected to default ICS logout page.

o Clock Skew: Specifies the maximum permitted time between the timestamps in the SAML Response (from IDP) and the clock on central time servers like NTP clock.

Service Provider Settings: Org Admin has to check/un-check the following properties. o Name Identifier value represents user's email address: If this is checked, ICS will use the

Name ID as email address also. o Sign Authentication Requests: If checked, ICS will sign authentication requests to IDP. o Sign Assertion (authentication response from Identity Provider): If checked, ICS

metadata XML (to IDP) will contain WantAssertionsSigned="true". o Sign Logout Requests: If checked, ICS will sign logout requests to IDP. o Encrypt Name Identifier in Logout Requests: If checked, ICS will encrypt Name ID in

logout request. (Note: Please check if your IDP supports decrypting NameIDs).

SAML Attribute Mapping to ICS User Fields: Based on IDP configuration, it will/can release/send user’s personal attributes (like First Name, Last Name, Email Address etc.) of the user/principal as part of the authentication response (Assertion). Org Admin will have to map these SAML Attributes to the following ICS User Fields:

o Use friendly SAML attribute names: If selected, uses SAML attribute's better human-readable form of the attribute's name which may be useful in cases in which the actual attribute Name is complex or opaque, such as an OID or a UUID.

o First Name o Last Name o Job Title o Email Addresses and Delimiter (if there are multiple email addresses in a SAML

response).

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 7

o Phone Number o Time Zone o User Roles and Delimiter (if there are multiple roles in a SAML response).

SAML Roles Mapping to ICS Roles: Org Admin will have to map SAML role names to ICS Roles (Designer, Admin and Service Consumer). Multiple SAML role names (separated by comma) can be mapped to a single ICS Role.

Default Role: Org Admin has to select a default ICS role name to be used as a user's role in case the SAML authentication response doesn't include SAML User Roles attribute.

Default User Group: If the Org has User Groups defined, then the Org Admin can select a default User Group for the SSO users.

Generate ICS SAML Metadata: Once IDP is configured, Org Admin clicks on a link/button to generate ICS SAML metadata (SAML Service Provider metadata). ICS will generate Service Provider metadata for use in SAML IDP and Org Admin can download that and give it to their SAML IDP Administrator. ICS also displays the SSO login URL for the Org.

Following is the sample ICS SAML metadata that will be generated:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://a1b2c3d4.icsserver.com"> <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="encryption"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>MIIDYDCCAkig.... </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>MIIDYDCCAkig... </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://icsserver.com/ma/slo/a1b2c3d4" /> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://icsserver.com/ma/acs/a1b2c3d4" /> </md:SPSSODescriptor>

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 8

</md:EntityDescriptor>

Note on ICS certificates: ICS certificates (both signing & encryption ones) are self-signed by Informatica

and are not CA-certified.

Note on non-Browser Clients: Non-Browser SAML 2.0 clients (Desktop, REST-API etc.) interaction with

ICS and IDP is governed by SAML 2.0 ECP profile. The authentication and logout location/URL @ IDP will

be different than the "SingleSignOnService URL" and "SingleLogoutService URL" mentioned above. As

and when ICS supports SAML based authentication/interaction with non-Browser clients, we will require

the Org Admin to specify their IDP ECP metadata (IDP authentication and logout service URLs). Also, the

ICS SAML metadata will include ECP related additions.

12 Authentication Request (ICS to IDP) Following figure is the SSO flow (copied from Wikipedia) for a user clicking on a custom ICS URL (specified to his/her ICS Org) for authentication into ICS. Note: ICS is represented by “Service Provider”, Web browser is represented by User Agent in the figure.

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 9

ICS will send the authentication request (<AuthnRequest>) to the “SingleSignOnService” location/URL at IDP. ICS will also send SAML “RelayState” parameter containing request specific and/or org-specific metadata to the IDP and IDP will send it back to ICS in the response. Here is a sample raw authentication request: <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"

AssertionConsumerServiceURL="https://icsserver.com/ma/acs/a1b2c3d4" ID="a1b2c3d4" IsPassive="false" IssueInstant="2013-12-09T05:33:50.821Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"> <samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion"> https://a1b2c3d4.icsserver.com </samlp:Issuer> <saml2p:NameIDPolicy Format=" urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </saml2p:AuthnRequest>

13 Authentication Response from IDP

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 10

SSO could be initiated by either ICS or by IDP. In both cases, the response from IDP to ICS will look the

same with minor differences.

Once ICS receives the SAML Response containing the Assertion, it will process the response as specified

in SAML 2 specification and summarized below:

All validations will be done as specified in SAML 2 specifications. This includes checking things

like Issuer, InResponseTo, NotBefore, SubjectConfirmation etc.

If the SAML response was signed, ICS will validate the signature using IDP’s public key.

If Assertion and/or NameID were encrypted, ICS will decrypt them using ICS’s private key.

13.1 ICS initiated SSO If the SSO request was initiated by ICS (upon user requesting an ICS resource) by sending an authentication request to IDP, IDP responds back with a SAML Response containing the Assertion(s). <saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://icsserver.com/ma/acs/a1b2c3d4" ID="b1c2d3e4" InResponseTo="a1b2c3d4" IssueInstant="2013-12-09T05:35:42.331Z" Version="2.0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.example.com </saml2:Issuer> <saml2p:Status> <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </saml2p:Status> <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="c1d2e3f4" IssueInstant="2013-12-09T06:01:16.836Z" Version="2.0"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.example.com </saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> … </ds:Signature> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" NameQualifier="https://idp.example.com" SPNameQualifier="https://a1b2c3d4.icsserver.com">user1@example.com</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData Address="192.168.1.8" InResponseTo="68ae653c-b15c-4261-97cd-f700936d4195"

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 11

NotOnOrAfter="2013-12-09T06:06:16.836Z" Recipient="https://icsserver.com/ma/acs/a1b2c3d4" /> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2013-12-09T06:01:16.836Z" NotOnOrAfter="2013-12-09T06:06:16.836Z"> <saml2:AudienceRestriction> <saml2:Audience>https://a1b2c3d4.icsserver.com</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2013-12-09T05:35:42.260Z" SessionIndex="_0130a424a83f10030b1b5cf785ea37f8"> <saml2:SubjectLocality Address="192.168.1.8" /> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> …

<saml2:AttributeStatement> <saml2:Attribute FriendlyName="cn" Name="urn:oid:2.5.4.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">user2</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="sn" Name="urn:oid:2.5.4.4" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">myLastName</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">xyz@abc.com</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement>

</saml2:Assertion> </saml2p:Response>

13.2 IDP initiated SSO

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 12

In this case, the user clicks on a link to ICS within IDP which will trigger IDP to authenticate the user (if not already authenticated) and issue SAML Response containing Assertion to ICS (Since IDP has the ICS SAML metadata, it knows where to send the SAML Response). The IDP initiated authentication response will look like same as the ICS initiated authentication request with the exception that the “InResponseTo” attribute won’t exist in “<Response>”.

14 NameId from IDP NameId cannot be a transient or temporary value (For example, NameId with

“urn:oasis:names:tc:SAML:2.0:nameid-format:transient” format) which could be different for each SSO

(or authentication response or <Assertion>). For a given user, each SSO into ICS (via SAML assertion

from IDP) should contain the same NameId value. The NameId value cannot be something that has no

discernible correspondence with the subject's actual identifier; instead it should be something like their

actual Username or Email address etc.

15 Encryption/Decryption and XML Signatures

15.1 Decryption IDP’s can be configured to encrypt any or all of <Assertion>, <NameID> and <Attribute>. ICS can

process/decrypt encrypted Assertions, NameIDs (within Assertion) and Attributes (inside an Assertion)

using ICS’s private key. If the decryption fails, then we won’t create ICS-User-Session for the

user/principal.

15.2 Sign & Validate Signature IDP’s can be configured to sign entire responses (authentication response, logout response) and/or

partial response (like signing an <Assertion>). ICS will validate the IDP signature (of entire response

and/or partial response) using IDP’s public key and if the signature validation fails, ICS will not

process/use the response.

If required by IDP, ICS can also sign LogoutRequest using ICS’s private key before sending it to IDP.

16 Logout from ICS When an IDP authenticated ICS user clicks on logout link in ICS, ICS will invalidate user’s ICS session and also send a logout request to the IDP’s “SingleLogoutService” URL.

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 13

We will be using SAML’s “Single Logout Profile” to end/invalidate user’s session at his/her IDP. The following figure (copied from SAML Profiles specification) illustrates the basic template for achieving single logout: Note: ICS is represented as “Session Participant”.

Here is how an ICS (SP) user logout is processed:

1. ICS prepares LogoutRequest and (if required by IDP) signs with it with ICS’s private key. 2. If required by IDP, ICS encrypts NameID in the logout request. 3. LogoutRequest issued by ICS to IDP 4. IDP determines authenticated SPs for given user session. If there are no SPs, other than ICS

(who sent logout request), the profile proceeds with step 5. Otherwise, steps 3 and 4 (in the above figure) are repeated for each SP.

5. LogoutRequest issued by IDP to SP 6. SP issues LogoutResponse to IDP 7. IDP issues LogoutResponse to ICS (who sent logout request) 8. ICS verifies LogoutResponse; if it was signed, validates signature using IDP’s Public key. 9. ICS invalidates & terminates ICS user-session.

Here is a sample SAML LogoutRequest sent by ICS to IDP: <saml2p:LogoutRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://idp.example.com/SLO" ID="a1b2c3d4" IssueInstant="2013-12-09T09:32:06.637Z" Reason="urn:oasis:names:tc:SAML:2.0:logout:user" Version="2.0">

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 14

<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://a1b2c3d4.icsserver.com </saml2:Issuer> <saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" NameQualifier="https://idp.example.com" SPNameQualifier="https://a1b2c3d4.icsserver.com">user1@example.com</saml2:NameID> </saml2p:LogoutRequest>

Once IDP receives the LogoutRequest from ICS and successfully invalidates the user session, IDP responds with LogoutResponse to ICS. A sample LogoutResponse is given below: <?xml version="1.0" encoding="UTF-8"?> <saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://sp.example.org/SamlLogout" ID="_337d88c34d2d82a4808316b967e3aea7" InResponseTo="a1b2c3d4" IssueInstant="2013-12-09T09:32:30.821Z" Version="2.0"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.example.com </saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

… </ds:Signature> <saml2p:Status> <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </saml2p:Status> </saml2p:LogoutResponse>

17 Org Provisioning & Enabling SAML SSO Org Provisioning: For provisioning a new Org, one has to either “Register for a New Account” through the web or use ICS

REST-API.

Licensing: We will be adding a new license and an Org will need that license to use SAML SSO functionality. This

new license will not be enabled (by default) as part of 30-day trials.

17.1 ICS Login URLs SSO Login URL: Each SAML SSO enabled Org will get a custom ICS login URL; this URL will contain Org-specific metadata

that would let ICS to load/lookup IDP SAML metadata for the Org so that ICS can send a SAML

authentication request which will lead SSO to ICS.

Non-SSO Login URL:

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 15

Irrespective whether SAML SSO is enabled or not, an Org would continue to use the default ICS login

URL which would use the ICS authentication where-in the user has to enter ICS Username & password.

17.2 Login from ICS REST-API and Registering Secure Agent

For login to ICS from REST-API and Registering Secure Agent, one has to continue to use ICS

Username/password even for Orgs enabled with SAML SSO.

18 What is in scope for this release The following are in-scope for first release of SAML SSO for ICS:

Configure SAML 2.0 based IDP for an Org.

SAML 2.0 based SSO to ICS using standard web browser.

SAML 2.0 based Logout from ICS

18.1 Limitations

ICS will work as a SAML 2.0 SP by federating authentication/SSO requests to a SAML 2.0 based

Identity Provider only and we won’t be supporting SSO to SAML 1.0 or non-SAML Identity

Providers.

The NameId value cannot be something that has no discernible correspondence with the

subject's actual identifier; instead it should be something like their actual Username or Email

address etc.

Agent registration, REST-API login has to use ICS username/password.

During Object Migration, the source org login credentials must be ICS username/password.

IDP's user session timeout will not be honored by ICS. Instead ICS’s user session timeout will be

used for the SSO user logged-in into ICS.

To begin with ICS will use IDP's HTTP-POST bindings only for "SingleSignOnService" and

"SingleLogoutService". We might later on support (or use) HTTP-Redirect bindings.

Required Attributes in SAML Assertion: ICS will require that IDP send at least Email Address, First

Name & Last Name attributes in the authentication response (<Assertion>).

19 What is not in scope of first release The following are not in scope of first release of SAML SSO for ICS.

_____________________________________________________________________________________

Informatica Cloud – Company Confidential Page 16

SAML based SSO using ICS REST-API

SAML based SSO using/from ICS Secure Agent (Secure Agent Manager & Secure Agent Console).

20 Open Items, TBD None