Ameritas Single Sign-On (SSO) and Enterprise SAML Standard. Architectural Implementation, Patterns and Usage Guidelines

Ameritas Single Sign-On (SSO) and Enterprise SAML Standard Architectural Implementation, Patterns and Usage Guidelines 1

Background and Overview... 3 Scope... 3 Glossary of Terms... 4 Architecture Components... 5 Conceptual Architecture Diagram... 5 Conceptual Architecture Diagram Component Description... 5 Browser Sessions... 5 Service Provider (SP) Connections... 6 Authentication Adapters... 6 External Authentication Sources... 7 Attribute Data Sources... 7 External Attribute Sources... 7 SAML Assertion... 7 SP Attribute Query Handler... 7 Service Provider (SP)... 8 IdP Initiated Single Sign-On Implementation Patterns... 9 SAML Assertion Definition and Requirements... 10 Authentication Method... 11 Internal Users... 11 External Users... 12 Identify the Data Source(s)... 13 SP Connection Configuration... 15 Initial Service Connection Configuration... 15 Browser SSO Configuration... 15 General Assertion Configuration... 16 Authentication Adapter Association... 16 Identifying Additional Attributes Optional... 16 Identity Attribute Mapping... 18 Protocol Settings... 19 Attribute Query Profile Optional But Rare... 19 SP Connection Activation... 21 Sample Implementation... 22 User Authentication and Portal Access... 22 SSO Authentication and SAML Assertion Processes... 23 Attribute Retrieval Processes... 23 SAML Assertion Processing... 24 SSO Completion and Browser Redirection... 24 SSO Implementation Checklists... 25 Service Provider Elements... 25 Identity Provider Elements... 25 2

Background and Overview Single Sign On (SSO) provides the ability for a User to access numerous applications and service providers by simply authenticating once for a given browser session. Once the user has authenticated into their primary domain (LAN, WAM Protected Website, etc.) the User is able to access other domains that trust the authentication assertion that SSO issues, to Service Providers, on the User s behalf. This assertion is facilitated through the use of SAML 2.0, which is Ameritas enterprise standard for security assertions. There are three primary actors that contribute during the SSO process: Principal This is the User that has authenticated into Ameritas domain and is initiating the access to another application or service via SSO using a web browser. Identity Provider (IdP) An IdP is responsible for verifying the identity of the User initiating the SSO event and asserting the Users authenticity and identity attributes to a Service Provider through a SAML token. Ameritas Enterprise Standard SAML vendor is Ping Identity s PingFederate software. Service Provider (SP) An SP is the consumer of identity attributes provided by the IdP through a SAML assertion. The SP application uses this information to set a valid session or other security context for the user represented by the identity attributes. An SP might be an internal Ameritas application, a SaaS provider or a business-process outsourcing vendor wanting to simplify client access to its services. SAML is XML-based which makes it a very flexible standard. Two federation partners (IdP and SP) can choose to share whatever identity attributes they want in a SAML assertion (message) payload as long as those attributes can be represented in XML. Example Use Case: An Ameritas Associate who is trying to access a remotely hosted Human Resources service provider to update their benefits information would click on the benefits link on the intranet. Ameritas' single sign on software would then send a security assertion token to the benefits supplier. The benefits supplier's SSO system would then take the token, check it and grant access to the Associate without making them sign on. Scope This document describes Ameritas Enterprise Standard for implementing Single Sign On called Identity Provider (IdP) initiated SSO using SAML 2.0 as the authentication exchange protocol. Single Sign On can be implemented in numerous variations and configurations. Other future implementations will be documented as required by the Enterprise. 3

Glossary of Terms The following table provides a list and definition of the various SSO terms and abbreviations contained within this document. Term/Abbreviation Definition A SAML XML document that contains identifying information about a particular subject; i.e., a person, company, application, Assertion or system. A SAML assertion can contain authentication, authorization, and attribute information about the subject A trust agreement between or among organizations, implemented using accepted standards, to provide userauthentication tokens and other user or system attributes Federation securely across domains, primarily to enable cross-domain SSO An IdP (Identity Provider) is a system entity that authenticates IdP a user and transmits referential identity attributes based on that authentication to PingFederate. Integrated Windows Authentication is an adapter that IWA authenticates a user in the specified domain using either the Kerberos v5 or Windows NT LAN Manager (NTLM) protocol. Security Assertion Markup Language (SAML) holds the dominant position in terms of industry acceptance for federated identity deployments. SAML is XML-based which makes it a very flexible standard. Two federation partners can SAML can choose to share whatever identity attributes they want in a SAML assertion (message) payload as long as those attributes can be represented in XML. SAML 2.0 is Ameritas enterprise standard for Security Assertions. An SP (Service Provider) is the consumer of identity attributes SP provided by the IdP through a SAML assertion. Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property SSO a user logs in once and gains access to all systems without being prompted to log in again at each of them Web access management (WAM) is a form of identity management that controls access to web resources, providing WAM authentication management, policy-based authorizations, audit, etc. Ameritas provider for WAM services is Symphony Solutions. 4

Architecture Components As mentioned previously, PingFederate is Ameritas Enterprise Standard vendor for SSO and SAML services. This section provides a high high-level level overview of the architecture and components that h have been deployed to enable SSO services, via SAML, to the Enterprise. Conceptual Architecture Diagram This diagram provides a conceptua conceptual overview of the architectural components that facilitate Ameritas SSO capability. These components are briefly described below. Conceptual Architecture Diagram Component Description The diagram presented above illustrates the purpose of and the interrelationships terrelationships between the various functional components that are utilized while constructing a security assertion and establishing a federation instance. Browser Sessions Browser-based based SSO (also, Browser SSO) is another term for secure Internet SSO, which relies on a User s web eb browser and HTTP to broker XML identity identity--federation messaging between an IdP and an SP SP.. In the context of SSO, the browser performs the following key functions as part of fulfilling an SSO request: SSO initiation via a page lin link or redirection Presentation of a Ping PingFederate Federate spawned credential challenge page, if required Redirection to the SP SP s target resource or successful SSO landing page Retrieval of session cookie data, if required to determine authentication SSO failure/error condition rreporting 5

Service Provider (SP) Connections Services Provider connections are internal PingFederate objects that instantiate the authentication agreement terms between the IdP and the SP. The SP Connections rely on other PingFederate components to perform specialized operations to complete its objectives. There is only one SP Connection for each IdP and SP combination. These connection objects perform the following key functions as part of construction and issuing a SAML assertion: Encapsulates IdP-SP relationship definitions and SAML assertion contract settings Defines IdP authentication mechanism(s) via PingFederate authentication adapters Defines the SAML assertion content including identity attributes (ie. SAML Subject) and extra context attributes (ie. email address, role, account number, etc.) Defines SAML assertion digital signing and encryption settings and techniques (typically via SSL certificated using a trusted Certificate Authority) Optionally, defines services to resolve and satisfy SP requests for additional attribute data during the assertion process Defines SP Integration Details including: o Connection Type: Browser-based SSO, WS-Trust STS, OAuth SAML Grant or Outbound Provisioning. Browser-based SSO is the Ameritas standard for IdP Initiated SSO o Bindings Type: HTTP Post, HTTP Artifact, HTTP Redirect (SAML 2.0) or SOAP (SAML 2.0) Authentication Adapters Authentication Adapters are internal PingFederate objects that serve as a interface between PingFederate s SP Connection objects and Ameritas internal authentication methods. These adapters perform the following functions while fulfilling an SSO request: Defines an interface to External Authentication (Ameritas) services as well as the expected authentication response token received from Ameritas authentication method Triggered by SP Connection when SSO request is initiated Authentication Adapter types include: o PingFederate or commercial Integration Adapters (IWA, NTLM, etc.) IWA is in Use Today o Custom (Java,.Net, PHP) Java-based custom Authentication Adapters are in use today o Authentication challenge web Pages Simple login and password entry forms are available 6

Composite Authentication Adapters allow multiple adapters to be daisychained or dynamically selected by PingFederate based on pre-defined criteria or the return code received from one of the daisy-chained adapters. External Authentication Sources External (to PingFederate) User authentication mechanisms that return the Authentication Token (via the Authentication Adapter) to the SP Connection object. Existing External Authentication Sources o Custom Java servlet that evaluates the contents of WAM cookie (Used for Internal and External Users) to validate the User o Kerberos (IWA Adapter) authentication against AD Controllers (Used for Internal Users) to validate the User o HTML credential challenge form (typically used if automatic authentication fails) that the User populates and submits to validate identity Future External Authentication Sources include other PingFederate Integration Kits, Custom Sources, etc. Attribute Data Sources Defines access (including credentials) to external attribute data sources that are queried to retrieve additional attribute information Provides additional attributes to the SP Connection for assertion inclusion Provides additional attribute fulfillment during SP Initiated Attribute Query operations Defines attributes to be retrieved from the external data source and query filter (where clause) information External Attribute Sources External repositories that are queried to retrieve attribute data needed to satisfy the assertion contract with Service Providers Types include: o JDBC o LDAP (AD Containers) o Oracle o SQL Server o Custom Web Services SAML Assertion Defined in the SP Connection object as agreed to by the Identity Provider and the Service Provider Sent to the Service Provider s SAML 2.0 Assertion Consumption URL Usually Base64 encoded SP Attribute Query Handler Defined in the SP Connection object 7

Handles additional attribute requests from the Service Provider back to the Identity Provider Accesses the appropriate data source to fulfill the request for additional attribute values. Service Provider (SP) Internal or external Partner that receives the SAML Assertion Validates Assertion (Public Key, Encryption, Assertion Attributes, etc.) Redirects User to appropriate URL if assertion is valid and accepted by the Service Provider 8

IdP Initiated Single Sign-On Implementation Patterns As previously mentioned, IdP initiated SSO is Ameritas primary method for implementing the SSO feature to provide seamless access to a Service Provider. There are numerous implementation options that enable PingFederate to satisfy the various business and security requirements that will be encountered during a SSO deployment. The available options and approaches are represented below as implementation patterns (use cases) that will serve as a catalyst for streamlining SSO deployments. The following outlines the high level activities that must occur to successfully implement SSO enabled access to a Service Provider: Establish IdP to SP SAML Assertion definition and requirements. This is usually well documented by the Service Provider but may require some direct interactions with the Service Provider s technical staff. Determine the Authentication Method that Ameritas will use to validate the identity of the User invoking SSO. Optionally, identify the data source(s) that will be used to collect additional attribute values to satisfy the requirements of the SAML Assertion. Configure the SP Connection to incorporate the various components as identified above. Rarely, configure Attribute Query Handling functionality, when mandated by the Service Provider. The remainder of this section further discusses these activities in greater detail. 9

SAML Assertion Definition and Requirements Typically a Service Provider will provide Ameritas with their SAML requirements in the form of a SAML/SSO User s Guide. This guide should provide the following critical information about making assertions to them: SAML Binding The Service Provider s acceptance of SAML 2.0 via Browser POST will be identified. This is Ameritas standard for making a SAML Assertion. SAML Subject Attribute This is the most common SAML attributed that is passed in the assertion and represents the SSO User s identity to the Service Provider. This is typically a unique identifier like LAN ID or WAM ID but can also be an opaque ID that doesn t directly identify the identity of the SSO User. SAML Encoding It is normal for the SAML Assertions to be base64 encoded. This is PingFederate s default setting. Some Service Providers make encoding optional however Ameritas standard recommends encoding when possible. SAML Signing Digitally signed SAML Assertions are customary and serve as one of the techniques that the Service Provider will use to verify that the Assertion is valid and issued by Ameritas. The existing PingFederate environments have SSL Certificates whose public key can be exported and shared with the Service Provider. SAML Time-out Value Another technique that Service Providers utilize to verify the SAML Assertion is to evaluate the Assertion s timestamp. Typically SAML Assertion have a 10 minute lifespan (five minutes before the time the assertion was created and five minutes after). This 10 minute range allows for inconsistencies that might exist between the IdP s system clock and the SP s system clock. Additionally, the Service Provider may provide Ameritas with a metadata file that is imported into PingFederate as part of the SP Connection creation process, documented below. This metadata file contains the following information that expedites the creation of the SP Connection: The Service Provider s Signing Certificate Public Key. The SP s URL that will be accepting the SAML Assertion. The entity id assigned to Ameritas by the Service Provider. This is also used by the SP to validate the assertion received from the IdP. 10

Authentication Method Verifying the authentication of a User, during an SSO operation, differs depending the User s proximity and the origination of the SSO enabled SP access point. The diagram below illustrates the two major points of origination for Ameritas Users, along with the existing PingFederate Authentication Adapters that support them. Internal Users Internal Users are typically authenticated when they log into the LAN with their LAN credentials (id and password). The following table presents the options for validating their identity in support of creating the SAML Assertion. Authentication Approach No Backup Authentication Mechanism Provide Backup Authentication Mechanism Authentication Adapter Value Returned to SP Connection Description KerberosIWA LAN ID The KerberosIWA adapter will verify that the User is valid by confirming with Active Directory controller KerberosIWA LAN ID The KerberosIWA adapter will (Primary) verify that the User is valid by confirming with Active Directory controller 11

Authentication Approach Authentication Adapter LoginForm (Secondary) Value Returned to SP Connection LAN ID Description Utilized if the KerberosIWA adapter fails to verify the validity of the User. A simple login form (containing User ID and Password fields) is presented to the User for authentication. External Users External Internet-based Users are typically authenticated when they log into one of Ameritas WAM protected internet sites (via service.ameritas.com for ProducerWorkbench, group.ameritas.com, etc.) using their WAM user id and password. The following table presents the options for validating their identity in support of creating the SAML Assertion. Authentication Approach No Backup Authentication Mechanism Provide Backup Authentication Mechanism Authentication Adapter Value Returned to SP Connection Description OTKWAMuser WAM ID This Java-based custom adapter will verify that the User has an active WAM browser cookie. OTKWAMuser WAM ID This Java-based custom adapter (Primary) will verify that the User has an active WAM browser cookie. LoginForm (Secondary) WAM ID Utilized if the OTKWAMuser adapter fails to verify the validity of the User. A simple login form (containing User ID and Password fields) is presented to the User for authentication. 12

Identify the Data Source(s) Occasionally, a Service Provider (SP) will require additional attribute values be included in the SAML Assertion provided by Ameritas, as the Identity Provider. These additional attribute values are made available to the SP Connection through the use of Attribute Data Sources. There are two scenarios that might require the definition and use of an Attribute Data Source: The SP requires something other than the SSO User s LAN or WAM ID (as returned from the Authentication Adapter) as the primary Identifying Attribute. In this case, the LAN or WAM ID must be used to query an external (to PingFederate) data source to retrieve the appropriate Identifying Attribute that will serve as the SAML Subject that is sent with the Assertion. The SP requires additional attribute information (such as system role, agency code, etc.) that is used by the SP to properly render their landing page once the User s SAML Assertion is validated. In these cases, there are steps that need to be performed to successfully facilitate the fulfillment of SAML data. The majority of the steps are performed within the PingFederate Adminstration Console via the System Settings/Data Stores link. Identify the external data source that will be queried to retrieve the additional attribute values based on the LAN or WAM ID. As mentioned in a previous section the external data source can be Active Directory (LDAP), SQL Server, Oracle or a Custom Web Service. If an existing external data source does not exist, it must be designed and populated using normal project processes and protocols. The data source must be defined and accessible prior to performing the subsequent activities. In most cases it is necessary to ensure that either the WAM ID or the LAN ID is included as a key column to support the query to retrieve the additional attribute values. In either case, the following required information must be known to complete the configuration of an External Data Store object. Data Store Type Connection String or Host Name Username or User DN Database, LDAP or Custom Database Source: This is the connection string that identifies the database server and the schema/database name LDAP Source: The Hostname(s) for the AD Repository (separated by a space) Database Source: This is the user ID that has access to query the schema/database name identified above. Typically a Service (functional) Account with read-only access. LDAP Source: This is the fully qualified Distinguished Name (DN) of the user account that has read access to repository defined 13

Password above. This is the password that is associated with either the User ID or User DN described above. 14

SP Connection Configuration Services Provider Connections are internal PingFederate objects that instantiate the authentication agreement terms between the IdP and the SP. These agreement terms as well as the other supporting configuration settings are presented below. Initial Service Connection Configuration The PingFederate Administrator begins the wizard-based process of creating a new SP Connection from the SP CONNECTIONS section of the IdP Configuration screen of the PingFederate Administration Portal. This section identifies the key activities that occur as part of the initial creation of a new SP Connection: Selection of the type of connection, based on templates, is required for the new Service Provider. At this time SAML 2.0-based Browser SSO Profiles is the only template that is supported. Selection of major SSO features that are utilized by the SP Connection. There are two available options: o Browser SSO This is required to support the creation of the SAML Assertion. o Attribute Query This feature is optional and enables the SP Connection to handle and respond to SP generated Attribute Queries that request additional information from Ameritas. PingFederate offers a utility that allows the Administrator to import many of the SP Connection settings from a metadata file that is received from the Service Provider. The definition of these settings is presented in a previous section. The process of importing the metadata file is available as a step in the setup wizard and involves identifying the location and name of the metadata file received from the SP. Additional general SP Connection settings are available to be reviewed and modified once the metadata file has been imported. These include: o Additional Service Provider information such as company name and contact information. o Special logging modes, which override system-wide settings, may also be selected for this new SP Connection. Browser SSO Configuration The wizard will guide the Administrator through the Browser SSO configuration settings which include the following: Select the types of SAML-based messages may be exchanged between the IdP and the SP. o IdP-Initiated SSO This is the only currently supported message type and the focus of this document. o SP-Initiated SSO Single Sign-on initiated by the Service Provider o IdP-Initiated SLO Single Log-off initiated by the IdP (Ameritas) o SP-Initiated SLO Single Log-ff initiated by the Service Provider Assertion timeframes which indicate the number of minutes prior to and after the assertion is issued that it remains valid. This is rarely changed and typically set to five minutes prior and five minutes after the issuance of the 15

Assertion. This range provides some margin for error in the event that the IdP s server clocks are not perfectly synchronized with SP s server clocks. General Assertion Configuration The wizard will guide the Administrator through the Assertion creation configuration settings which include the following: Specification of the identity attribute s data type: o Standard As the name suggests this is the usual way the identity attribute value is sent to the SP. In this case, the attribute value is not altered or masked while it is being sent to the SP. o Pseudonym The identity attribute value is sent as an opaque nonidentifiable value that preserves the user s actual identity and privacy. This typically requires the use of cross reference tables on both the IdP and SP systems. o Transient The identity attribute value is a temporary opaque identifies that is sent to the SP. Identification of the Assertion s critical identity attributes settings. This is typically a single attribute that is sent to the Service Provider using the SAML_SUBJECT SAML Attribute. Authentication Adapter Association The wizard will guide the Administrator through identifying the previously defined Authentication Adapter that will verify the SSO User s authentication prior to creating the assertion. The following identifies the tasks performed during this activity: Selection of the Authentication Adapter(s) to employ from the list of available Adapters. Once the desired Adapter is selected a list of the available attributes that can be retrieved from the Adapter is presented as documentation. If a Composite Adapter is employed, PingFederate requires that all member Adapters also be selected here along with the Composite Adapter itself. Identification of the attribute(s) that will be provided as part of the Attribute Contract fulfillment with the SP. The options available for Attribute Contract fulfillment are: o Use only the Attribute values that are directly received from the Authentication Adapter. o Retrieve additional attributes from multiple External Data Sources using a single mapping. o Retrieve additional attributes from an External Data Source and provide alternative data sources. Identifying Additional Attributes Optional If additional attributes are required, based on the following scenarios, review and perform the activities described in this section: The Service Provider requires an identity attribute that is not directly returned by the Authentication Adapter. In this case, the WAM or LAN ID will 16

be used to query an external data source for the information to forward to the SP as the identity attribute. There is additional information that must be passed to the Service Provider as SAML Assertion payload. In this case, the WAM or LAN ID (which may or may not be the identity attribute) is used to query the external data source(s) for the additional information to send with the Assertion. The following steps are performed by the Administrator, via the wizard, to enable additional attributes to be accessed by the SP Connection: The desired Data Source must be identified. There are several required pieces of information that must be provided during this step: o The Data Source is given a unique but meaningful name (ID) and description for this SP Connection. An example for the name might be ORARepTable and the description might be Oracle table with registered rep numbers. o Select the Data Source object from the available list of previously defined active Data Source objects. Once the Data Source has been identified, the Administrator will be asked to identify the desired database table and column. The options for this task are defined below: o Select the database schema that contains the desired table from the list of available schemas. o Select the database table that contains the desired column from the list of available tables for the selected schema. o Select and add the desired columns that will be used by the SP Connection. The wizard will now require the Administrator to identify the where clause that will be used to filter the data from the table selected above. The format for the where clause is very similar to a standard SQL where clause except the word where is omitted when authoring the condition. The following provides an example of a typical PingFederate where clause: WAMID=${subject} o The left hand side of the equal sign (=) is the column name of the selected table whose values will be searched to find the match to the right hand side of the equal sign. o The right hand side of the equal sign (=) is the value to search for. This element typically uses PingFederate s ${attribute} syntax which represents an internally stored token or attribute received from the Authentication Adapter. 17

Identity Attribute Mapping Identify the Identity Attribute to map to the SAML_SUBJECT value in the assertion. This activity is also known as identifying the attribute contract fulfillment information: Select the Source of the identity attribute. A list of Sources is provided to the administrator. The available selections are: o Adapter This source instructs the SP Connection to use a token received from the Authentication Adapter as the identity attribute. o Context This source instructs the SP Connection to use values that are returned from the context of the transaction at runtime. o Text This source instructs the SP Connection to use the value that you enter. This can be text only, or you can mix text with references to any of the values from the adapter, using PingFederate s ${attribute} syntax. o JDBC This source instructs the SP Connection to retrieve the identity attribute from an external data store that is a database. o LDAP This source instructs the SP Connection to retrieve the identity attribute from an external data store that is an Active Directory repository. Once the identity attribute source has been selected, the administrator will be presented options for identifying the attribute to serve as the identity attribute in the assertion. The following illustrates the common options based on the source type: o Adapter A list of attributes(s) that are returned from the Authentication Adapter(s) is presented. In this case, the value returned from the Authentication Adapter will be used as the identity attribute. o Context A list of available context-specific attributes will be presented. This list includes Target Resource, Authentication Context, Client IP or HTTP Request. o Text A blank text field is presented that allows the Administrator to enter a literal text value which can include reference tags. As an example; the literal value AIC-${subject} would resolve to a value that is a concatenation of the literal AIC- and the WAM ID of SSO user (eg. AIC-briley ). o JDBC A screen is presented that allows the Administrator to identify the database column that will be used as the identity attribute. Additionally, a database filter is required that essentially serves as the where clause portion of the query that retrieves the attribute value from the database. o LDAP A screen is presented that allows the Administrator to identify the LDAP Attribute that will be used as the identity attribute. Additionally, the Administrator will be asked to provide information to control the repository query such as Base DN, Search Scope, Root Object Class, etc. 18

Protocol Settings The wizard will guide the Administrator through identifying the configuration for specific endpoints and security considerations applicable to this SP Connection. The key configuration settings in this activity are: Binding Type This is identifies the specific SAML transport protocol that is used for this SP Connection. Typically this is set to the value of POST. EndPoint URL This is the Service Provider s URL that is used to consume the SAML assertion. This is usually contained in the metadata that is imported. Assertion Signing This option, which provides additional guarantees of authenticity for the assertion, should be selected if mutually agreed to with the Service Provider. Assertion Encryption One of these options, which provides additional guarantees of privacy for the assertion, should be selected if mutually agreed to with the Service Provider: o None No encryption is performed for this assertion. o The Entire Assertion The complete Assertion is encrypted. o One or More Attributes Select attribute can be encrypted while others are sent in clear (although encoded) text. Attribute Query Profile Optional But Rare If the Attribute Query feature was selected back in the Initial Service Connection Configuration section the following activities must be performed to configure the feature: Specify the name of the attribute that is returned to the Service Provider during an Attribute Query request. This name should be agreed upon with the Service Provider. The desired Data Source must be identified. There are several required pieces of information that must be provided during this step: o The Data Source is given a unique but meaningful name (ID) and description for this SP Connection. An example for the name might be ORARepTable and the description might be Oracle table with registered rep numbers. o Select the Data Source object from the available list of previously defined active Data Source objects. Once the Data Source has been identified, the Administrator will be asked to identify the desired database table and column. The options for this task are defined below: o Select the database schema that contains the desired table from the list of available schemas. o Select the database table that contains the desired column from the list of available tables for the selected schema. o Select and add the desired columns that will be used by the SP Connection. 19

The wizard will now require the Administrator to identify the where clause that will be used to filter the data from the table selected above. The format for the where clause is very similar to a standard SQL where clause except the word where is omitted when authoring the condition. The following provides an example of a typical PingFederate where clause: WAMID=${subject} o The left hand side of the equal sign (=) is the column name of the selected table whose values will be searched to find the match to the right hand side of the equal sign. o The right hand side of the equal sign (=) is the value to search for. This element typically uses PingFederate s ${attribute} syntax which represents an internally stored token or attribute received from the Authentication Adapter. Select the Source of the query attribute to be returned by the Attribute Query feature. A list of Sources is provided to the administrator. The available selections are: o Context This source instructs the SP Connection to use values that are returned from the context of the transaction at runtime. o Text This source instructs the SP Connection to use the value that you enter. This can be text only, or you can mix text with references to any of the values from the adapter, using PingFederate s ${attribute} syntax. o JDBC This source instructs the SP Connection to retrieve the identity attribute from an external data store that is a database. o LDAP This source instructs the SP Connection to retrieve the identity attribute from an external data store that is an Active Directory repository. Once the identity attribute source has been selected, the administrator will be presented options for identifying the attribute to serve as the identity attribute in the assertion. The following illustrates the common options based on the source type: o Context A list of available context-specific attributes will be presented. This list includes Target Resource, Authentication Context, Client IP or HTTP Request. o Text A blank text field is presented that allows the Administrator to enter a literal text value which can include reference tags. As an example; the literal value AIC-${subject} would resolve to a value that is a concatenation of the literal AIC- and the WAM ID of SSO user (eg. AIC-briley ). o JDBC A screen is presented that allows the Administrator to identify the database column that will be used as the identity attribute. 20

Additionally, a database filter is required that essentially serves as the where clause portion of the query that retrieves the attribute value from the database. o LDAP A screen is presented that allows the Administrator to identify the LDAP Attribute that will be used as the identity attribute. Additionally, the Administrator will be asked to provide information to control the repository query such as Base DN, Search Scope, Root Object Class, etc. Identify the security policy associate with this Attribute Query Handler. Available options are defined below: o Sign the Response The response to the Service Provider s attribute request is signed using Ameritas Signing Certificate. o Sign the Assertion - The Assertion sent back as part of the Service Provider s attribute request is signed using Ameritas SSL Certificate. o Encrypt the Assertion - The Assertion sent back as part of the Service Provider s attribute request is encrypted using Ameritas encryption certificate. o Require Signed Attribute Query This indicates that the Attribute Query received from the Service Provider must be signed by the SP using their Signing Certificate. This requires Ameritas to have the SP s Signing Certificate s Public Key. o Require an Encrypted Name Identifier - This indicates that the Name Identifier portion of the Attribute Query received from the Service Provider must be encrypted by the SP using their Encryption Certificate. This requires Ameritas to have the SP s Encryption Certificate s Public Key. Identify the Attribute Query Handler Authentication type. Available options are defined below: o HTTP Basic Indicates that the Service Provider must provide a Login ID and Password as part of Attribute Query request. o SSL Client Certificate Indicates that the Service Provider must provide an SSL Certificate as part of authenticating the Attribute Query request. o Digital Signature Indicates that the Attribute Query request must be digitally signed. o Require SSL Indicates that the Attribute Query request must be made using the HTTPS transmission channel. SP Connection Activation Once the SP Connection has been successfully configured, it can be activated and testing can begin. The Activation & Summary screen for the SP Connection contains the SSO Application Endpoint which is used by the User to invoke the newly created SSO connection. This URL is ultimately made available to the User, as the SSO link, on a new or existing Ameritas web page. 21

Sample Implementation This section provides an overview of a sample SSO enabled integration to illustrate the implementation of one of the anticipated SSO usage patterns. This sample implementation has the following characteristics: The SSO user can be either an internal Ameritas Associate or an external person accessing an Ameritas Portal page page. Since all Ameritas Portal page Users must authenticate and receive a WAM browser cookie, the External User Authentication pattern will be employed. In this scenario the Service Provider expects additional attribute values to accompany the SAML Assertion. Consequently, the Oracle Attribute Data Source pattern will be employed to satisfy this requirement. Upon acceptance of the SAML Assertion the SSO user will be redirected to the Service Providers landing page. The following diagram conceptually illustrates the actions and response to successfully execute the scenario described above. Each of the components and interfaces/interactions presented are briefly described below. User Authentication and Portal Acce Access These components and integrations represent the actions and responses that are performed during the process of a User logging into the Ameritas web site and system presenting them with the screen that contains the SSO enabled link. This section presents a high-level evel overview of these steps, in minimal detail, with the sole purpose of adding context to this overview. 1. The User uses a standard browser to access a WAM WAM-protected protected Ameritas URL where they are challenged for their identity credentials via a standard stan login screen. 22

2. Once the User supplies their credentials, their identity information is processed by Ameritas security infrastructure and if valid, a WAM cookie is instantiated in their browser. 3. The User navigates to the desired web page and clicks the SSO enabled link to gain access to the Service Provider s system. This action initiates the SSO processes that have been presented in this document. SSO Authentication and SAML Assertion Processes These components and integrations represent the actions and responses that are performed once the User invokes the SSO enabled link described above. 1. The SSO request is sent via secure HTTP to the URL contained in the SSO enabled link. This URL resolves to one of the PingFederate engines and also contains a reference to the SP Connection that is responsible for handling SSO requests to the desired Service Provider. 2. PingFederate accepts the SSO request and instantiates the required SP Connection and begins processing the SSO request. 3. The SP Connection will instantiate and execute the appropriate WAM Authentication Adapter (OTKWAMuser in this example) to validate the User s identity. 4. The WAM Authentication Adapter will execute the associated Open Token Custom Java Servlet (OTKWAMuser in this example) that runs on the Ameritas WebSphere Application Servers. 5. The Open Token Java Servlet will evaluate the contents of the User s browser-based WAM cookie to ensure it is present, active and valid. This serves as confirmation that the User is valid. This servlet also retrieves the User s WAM ID from the cookie and returns it back to the Authentication Adapter and terminates processing. 6. The Authentication Adapter receives the WAM ID from the Java Servlet and passes it on to the SP Connection as the security token. The Authentication Adapter s portion of the process is now complete and it is terminated. Attribute Retrieval Processes These components and integrations represent the actions and responses that are initiated once the SP Connection has received the successful security token and is processing the acquisition of the remaining attribute required by the SAML assertion. 1. The SP Connection will instantiate and execute the appropriate Data Source object (Oracle in this example) to process its pre-defined query. This query will utilize the WAM ID received, via the previously created security token, as a portion of its where clause. 2. The Data Source object will execute the query against the associated External Data Source (Oracle in this example) and retrieve the resulting attribute values for continued processing. 3. The SP Connection accepts the attributes retrieved from the Data Source object and continue processing. The Data Source object is terminated. 23

SAML Assertion Processing These components and integrations represent the actions and responses that are initiated once the SP Connection has received the extra attributes from the Data Source process and initiates the SAML Assertion processes. 1. Once the SP Connection has received confirmation about the User s identity and retrieved the necessary extra attributes the SAML Assertion is assembled. 2. The SAML Assertion is digitally signed using Ameritas signing certificate and given the appropriate timestamp. 3. The required SAML Assertion elements (or the whole Assertion) are encrypted using Ameritas encryption certificate. 4. The SAML assertion is base64 encoded and sent to the URL specified as the Service Provider s Assertion consumption URL. 5. The SP Connection receives confirmation from the Service Provider that the Assertion was received, processed and accepted. SSO Completion and Browser Redirection These components and integrations complete the SSO processing initiated in this sample use case. 1. The SP Connection will send a browser redirection response back to the SSO User s browser. 2. The SSO User s browser will process the redirection response and the user will be redirected to the Service Provider s landing page. 24

SSO Implementation Checklists The following provides a concise checklist for the various items that are required to configure and successfully implement SSO within the Ameritas environment. Service Provider Elements These items should be provided by the Service Provider when Ameritas is enabling SSO into their site(s). SSO Component Metadata file SAML Profile Identity Attribute Additional Attributes Digital Signing and Encryption Requirements Additional Features Description This file is received from the SP and contains a significant number of the elements that are required to configure the Ameritas IdP SSO settings. See section SAML Assertion Definition and Requirements of this document for additional information. SAML 1.1 or SAML 2.0 is typically accepted profiles by the SP. Ameritas standards dictate the SAML 2.0 is required. This is the key information that is sent as the SAML_SUBJECT portion of the SAML Assertion. The individual implementation project teams will have to determine how to supply the appropriate value for this attribute. The Identity Attribute Mapping section of this document provides additional information on retrieving additional attribute values. These attributes may be additional payload that accompany the SAML Assertion and are used by the SP to control access within their site. These are typically agreed upon during SSO design sessions with the SP s SSO team. This information can typically be found in the SP s SSO documentation. Occasionally, the SP may require additional SAML and SSO features such as Attribute Query, Auto-Provisioning, etc. These requirements will be addressed on a case by case basis. Identity Provider Elements These items should be provided to the Service Provider when Ameritas is enabling SSO into their site(s). SSO Component Metadata file Additional Features Description This file is created from the PingFederate Administration Console and provides the SP with Ameritas key information. This includes Ameritas URL information, public keys for digital signing and encryption certificate. Occasionally, the SP may require additional SAML and SSO features such as Attribute Query, Auto-Provisioning, etc. These requirements will require Ameritas to supply additional information to the SP including Attribute Query URL Location, etc. 25