Ameritas Single Sign-On (SSO) and Enterprise SAML Standard. Architectural Implementation, Patterns and Usage Guidelines
|
|
- Juliana Gallagher
- 8 years ago
- Views:
Transcription
1 Ameritas Single Sign-On (SSO) and Enterprise SAML Standard Architectural Implementation, Patterns and Usage Guidelines 1
2 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 Authentication Method Internal Users External Users Identify the Data Source(s) SP Connection Configuration Initial Service Connection Configuration Browser SSO Configuration General Assertion Configuration Authentication Adapter Association Identifying Additional Attributes Optional Identity Attribute Mapping Protocol Settings Attribute Query Profile Optional But Rare SP Connection Activation Sample Implementation User Authentication and Portal Access SSO Authentication and SAML Assertion Processes Attribute Retrieval Processes SAML Assertion Processing SSO Completion and Browser Redirection SSO Implementation Checklists Service Provider Elements Identity Provider Elements
3 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
4 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
5 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
6 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. 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
7 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
8 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
9 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
10 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
11 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
12 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
13 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
14 Password above. This is the password that is associated with either the User ID or User DN described above. 14
15 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
16 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
17 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
18 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
19 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
20 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
21 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
22 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
23 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
24 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
25 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
Implementation Guide SAP NetWeaver Identity Management Identity Provider
Implementation Guide SAP NetWeaver Identity Management Identity Provider Target Audience Technology Consultants System Administrators PUBLIC Document version: 1.10 2011-07-18 Document History CAUTION Before
More informationUsing SAML for Single Sign-On in the SOA Software Platform
Using SAML for Single Sign-On in the SOA Software Platform SOA Software Community Manager: Using SAML on the Platform 1 Policy Manager / Community Manager Using SAML for Single Sign-On in the SOA Software
More informationThis chapter describes how to use the Junos Pulse Secure Access Service in a SAML single sign-on deployment. It includes the following sections:
CHAPTER 1 SAML Single Sign-On This chapter describes how to use the Junos Pulse Secure Access Service in a SAML single sign-on deployment. It includes the following sections: Junos Pulse Secure Access
More informationPingFederate. Salesforce Connector. Quick Connection Guide. Version 4.1
PingFederate Salesforce Connector Version 4.1 Quick Connection Guide 2011 Ping Identity Corporation. All rights reserved. PingFederate Salesforce Quick Connection Guide Version 4.1 June, 2011 Ping Identity
More informationFlexible Identity Federation
Flexible Identity Federation Quick start guide version 1.0.1 Publication history Date Description Revision 2015.09.23 initial release 1.0.0 2015.12.11 minor updates 1.0.1 Copyright Orange Business Services
More informationPingFederate. SSO Integration Overview
PingFederate SSO Integration Overview 2006-2012 Ping Identity Corporation. All rights reserved. PingFederate SSO Integration Overview Version 6.6 January, 2012 Ping Identity Corporation 1001 17th Street,
More informationSAML-Based SSO Solution
About SAML SSO Solution, page 1 SAML-Based SSO Features, page 2 Basic Elements of a SAML SSO Solution, page 2 SAML SSO Web Browsers, page 3 Cisco Unified Communications Applications that Support SAML SSO,
More informationThe increasing popularity of mobile devices is rapidly changing how and where we
Mobile Security BACKGROUND The increasing popularity of mobile devices is rapidly changing how and where we consume business related content. Mobile workforce expectations are forcing organizations to
More informationPingFederate. IWA Integration Kit. User Guide. Version 3.0
PingFederate IWA Integration Kit Version 3.0 User Guide 2012 Ping Identity Corporation. All rights reserved. PingFederate IWA Integration Kit User Guide Version 3.0 April, 2012 Ping Identity Corporation
More informationTenrox. Single Sign-On (SSO) Setup Guide. January, 2012. 2012 Tenrox. All rights reserved.
Tenrox Single Sign-On (SSO) Setup Guide January, 2012 2012 Tenrox. All rights reserved. About this Guide This guide provides a high-level technical overview of the Tenrox Single Sign-On (SSO) architecture,
More informationPingFederate. IWA Integration Kit. User Guide. Version 2.6
PingFederate IWA Integration Kit Version 2.6 User Guide 2012 Ping Identity Corporation. All rights reserved. PingFederate IWA Integration Kit User Guide Version 2.6 March, 2012 Ping Identity Corporation
More information000-575. IBM Tivoli Federated Identity Manager V6.2.2 Implementation. Version: Demo. Page <<1/10>>
000-575 IBM Tivoli Federated Identity Manager V6.2.2 Implementation Version: Demo Page 1.What is the default file name of the IBM Tivoli Directory Integrator log? A. tdi.log B. ibmdi.log C. ibmdisrv.log
More informationCA Performance Center
CA Performance Center Single Sign-On User Guide 2.4 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation ) is
More informationIntegrating VMware Horizon Workspace and VMware Horizon View TECHNICAL WHITE PAPER
Integrating VMware Horizon Workspace and VMware Horizon View TECHNICAL WHITE PAPER Table of Contents Introduction.... 3 Requirements.... 3 Horizon Workspace Components.... 3 SAML 2.0 Standard.... 3 Authentication
More informationGet Success in Passing Your Certification Exam at first attempt!
Get Success in Passing Your Certification Exam at first attempt! Exam : C2150-575 Title : IBM Tivoli Federated Identity Manager V6.2.2 Implementation Version : Demo 1.What is the default file name of the
More informationCA Nimsoft Service Desk
CA Nimsoft Service Desk Single Sign-On Configuration Guide 6.2.6 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation
More informationPingFederate. Integration Overview
PingFederate Integration Overview 2008 Ping Identity Corporation. All rights reserved. Part Number 3007-321 January, 2008 Ping Identity Corporation 1099 18th Street, Suite 2950 Denver, CO 80202 U.S.A.
More informationDEPLOYMENT GUIDE. SAML 2.0 Single Sign-on (SSO) Deployment Guide with Ping Identity
DEPLOYMENT GUIDE SAML 2.0 Single Sign-on (SSO) Deployment Guide with Ping Identity Table of Contents SAML Overview...3 Integration Topology...3 Deployment Requirements...4 Configuration Steps...4 Step
More informationCloud Single Sign-On and On-Premise Identity Federation with SAP NetWeaver Cloud White Paper
Cloud Single Sign-On and On-Premise Identity Federation with SAP NetWeaver Cloud White Paper TABLE OF CONTENTS INTRODUCTION... 3 Where we came from... 3 The User s Dilemma with the Cloud... 4 The Administrator
More informationMcAfee Cloud Identity Manager
SAML2 Cloud Connector Guide McAfee Cloud Identity Manager version 1.2 or later COPYRIGHT Copyright 2013 McAfee, Inc. All Rights Reserved. No part of this publication may be reproduced, transmitted, transcribed,
More informationAuthentication Methods
Authentication Methods Overview In addition to the OU Campus-managed authentication system, OU Campus supports LDAP, CAS, and Shibboleth authentication methods. LDAP users can be configured through the
More informationHP Software as a Service. Federated SSO Guide
HP Software as a Service Federated SSO Guide Document Release Date: July 2014 Legal Notices Warranty The only warranties for HP products and services are set forth in the express warranty statements accompanying
More informationINUVIKA OPEN VIRTUAL DESKTOP ENTERPRISE
INUVIKA OPEN VIRTUAL DESKTOP ENTERPRISE SAML 2.0 CONFIGURATION GUIDE Roy Heaton David Pham-Van Version 1.1 Published March 23, 2015 This document describes how to configure OVD to use SAML 2.0 for user
More informationAD FS 2.0 Step-by-Step Guide: Federation with Ping Identity PingFederate
AD FS 2.0 Step-by-Step Guide: Federation with Ping Identity PingFederate Ping Identity Corporation and Microsoft Corporation Published: November 2010 Version: 1.0 Author: Dave Martinez, Principal, Martinez
More informationIBM WebSphere Application Server
IBM WebSphere Application Server SAML 2.0 web single-sign-on 2012 IBM Corporation This presentation describes support for SAML 2.0 web browser Single Sign On profile included in IBM WebSphere Application
More informationGetting Started with AD/LDAP SSO
Getting Started with AD/LDAP SSO Active Directory and LDAP single sign- on (SSO) with Syncplicity Business Edition accounts allows companies of any size to leverage their existing corporate directories
More informationEnabling Federation and Web-Single Sign-On in Heterogeneous Landscapes with the Identity Provider and Security Token Service Supplied by SAP NetWeaver
Enabling Federation and Web-Single Sign-On in Heterogeneous Landscapes with the Identity Provider and Security Token Service Supplied by SAP NetWeaver SAP Product Management, SAP NetWeaver Identity Management
More informationEgnyte Single Sign-On (SSO) Configuration for Active Directory Federation Services (ADFS)
w w w. e g n y t e. c o m Egnyte Single Sign-On (SSO) Configuration for Active Directory Federation Services (ADFS) To set up ADFS so that your employees can access Egnyte using their ADFS credentials,
More informationFlexible Identity Federation
Flexible Identity Federation Administration guide version 1.0.1 Publication history Date Description Revision 2015.09.24 initial release 1.0.0 2015.12.11 minor updates 1.0.1 Copyright Orange Business Services
More informationIntroduction to Directory Services
Introduction to Directory Services Overview This document explains how AirWatch integrates with your organization's existing directory service such as Active Directory, Lotus Domino and Novell e-directory
More informationSAML-Based SSO Solution
About SAML SSO Solution, page 1 SAML-Based SSO Features, page 2 Basic Elements of a SAML SSO Solution, page 2 SAML SSO Web Browsers, page 3 Cisco Unified Communications Applications that Support SAML SSO,
More informationFederated Identity Management Solutions
Federated Identity Management Solutions Jyri Kallela Helsinki University of Technology jkallela@cc.hut.fi Abstract Federated identity management allows users to access multiple services based on a single
More informationPHP Integration Kit. Version 2.5.1. User Guide
PHP Integration Kit Version 2.5.1 User Guide 2012 Ping Identity Corporation. All rights reserved. PingFederate PHP Integration Kit User Guide Version 2.5.1 December, 2012 Ping Identity Corporation 1001
More informationIMPLEMENTING SINGLE SIGN- ON USING SAML 2.0 ON JUNIPER NETWORKS MAG SERIES JUNOS PULSE GATEWAYS
APPLICATION NOTE IMPLEMENTING SINGLE SIGN- ON USING SAML 2.0 ON JUNIPER NETWORKS MAG SERIES JUNOS PULSE GATEWAYS SAML 2.0 combines encryption and digital signature verification across resources for a more
More informationConnected Data. Connected Data requirements for SSO
Chapter 40 Configuring Connected Data The following is an overview of the steps required to configure the Connected Data Web application for single sign-on (SSO) via SAML. Connected Data offers both IdP-initiated
More informationSingle Sign-On Implementation Guide
Salesforce.com: Salesforce Winter '09 Single Sign-On Implementation Guide Copyright 2000-2008 salesforce.com, inc. All rights reserved. Salesforce.com and the no software logo are registered trademarks,
More informationPingFederate. Windows Live Cloud Identity Connector. User Guide. Version 1.0
Windows Live Cloud Identity Connector Version 1.0 User Guide 2011 Ping Identity Corporation. All rights reserved. Windows Live Cloud Identity Connector User Guide Version 1.0 April, 2011 Ping Identity
More informationPARTNER INTEGRATION GUIDE. Edition 1.0
PARTNER INTEGRATION GUIDE Edition 1.0 Last Revised December 11, 2014 Overview This document provides standards and guidance for USAA partners when considering integration with USAA. It is an overview of
More informationStep-by-Step guide for SSO from MS Sharepoint 2010 to SAP EP 7.0x
Step-by-Step guide for SSO from MS Sharepoint 2010 to SAP EP 7.0x Sverview Trust between SharePoint 2010 and ADFS 2.0 Use article Federated Collaboration with Shibboleth 2.0 and SharePoint 2010 Technologies
More informationCopyright: WhosOnLocation Limited
How SSO Works in WhosOnLocation About Single Sign-on By default, your administrators and users are authenticated and logged in using WhosOnLocation s user authentication. You can however bypass this and
More informationAn Oracle White Paper Dec 2013. Oracle Access Management Security Token Service
An Oracle White Paper Dec 2013 Oracle Access Management Security Token Service Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only,
More informationUSING FEDERATED AUTHENTICATION WITH M-FILES
M-FILES CORPORATION USING FEDERATED AUTHENTICATION WITH M-FILES VERSION 1.0 Abstract This article provides an overview of federated identity management and an introduction on using federated authentication
More informationConfiguring ADFS 3.0 to Communicate with WhosOnLocation SAML
Configuring ADFS 3.0 to Communicate with WhosOnLocation SAML --------------------------------------------------------------------------------------------------------------------------- Contents Overview...
More informationSAML Security Option White Paper
Fujitsu mpollux SAML Security Option White Paper Fujitsu mpollux Version 2.1 February 2009 First Edition February 2009 The programs described in this document may only be used in accordance with the conditions
More informationSiteminder Integration Guide
Integrating Siteminder with SA SA - Siteminder Integration Guide Abstract The Junos Pulse Secure Access (SA) platform supports the Netegrity Siteminder authentication and authorization server along with
More informationWeb Services Security: OpenSSO and Access Management for SOA. Sang Shin Java Technology Evangelist Sun Microsystems, Inc. javapassion.
Web Services Security: OpenSSO and Access Management for SOA Sang Shin Java Technology Evangelist Sun Microsystems, Inc. javapassion.com 1 Agenda Need for Identity-based Web services security Single Sign-On
More informationGetting Started with Single Sign-On
Getting Started with Single Sign-On I. Introduction Your institution is considering or has already purchased Collaboratory from Treetop Commons, LLC. One benefit provided to member institutions is Single
More informationSAP NetWeaver AS Java
Chapter 75 Configuring SAP NetWeaver AS Java SAP NetWeaver Application Server ("AS") Java (Stack) is one of the two installation options of SAP NetWeaver AS. The other option is the ABAP Stack, which is
More informationHOTPin Integration Guide: Salesforce SSO with Active Directory Federated Services
1 HOTPin Integration Guide: Salesforce SSO with Active Directory Federated Services Disclaimer Disclaimer of Warranties and Limitation of Liabilities All information contained in this document is provided
More informationVMware Identity Manager Administration
VMware Identity Manager Administration VMware Identity Manager 2.4 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new
More informationNew Single Sign-on Options for IBM Lotus Notes & Domino. 2012 IBM Corporation
New Single Sign-on Options for IBM Lotus Notes & Domino 2012 IBM Corporation IBM s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM s sole
More informationIT@Intel. Improving Security and Productivity through Federation and Single Sign-on
White Paper Intel Information Technology Computer Manufacturing Security Improving Security and Productivity through Federation and Single Sign-on Intel IT has developed a strategy and process for providing
More informationTIBCO Spotfire Web Player 6.0. Installation and Configuration Manual
TIBCO Spotfire Web Player 6.0 Installation and Configuration Manual Revision date: 12 November 2013 Important Information SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED
More informationSAML Single-Sign-On (SSO)
C O L A B O R A T I V E I N N O V A T I O N M A N A G E M E N T Complete Feature Guide SAML Single-Sign-On (SSO) 1. Features This feature allows administrators to setup Single Sign-on (SSO) integration
More informationIdentity Management in Liferay Overview and Best Practices. Liferay Portal 6.0 EE
Identity Management in Liferay Overview and Best Practices Liferay Portal 6.0 EE Table of Contents Introduction... 1 IDENTITY MANAGEMENT HYGIENE... 1 Where Liferay Fits In... 2 How Liferay Authentication
More informationUNIVERSITY OF COLORADO Procurement Service Center INTENT TO SOLE SOURCE PROCUREMENT CU-JL39027649-SS. Single Sign-On (SSO) Solution
UNIVERSITY OF COLORADO Procurement Service Center INTENT TO SOLE SOURCE PROCUREMENT CU-JL39027649-SS Single Sign-On (SSO) Solution For University Information Systems (UIS) May 9, 2013 2 University of Colorado
More informationCA Single Sign-On Migration Guide
CA Single Sign-On Migration Guide Web access management (WAM) systems have been a part of enterprises for decades. It is critical to control access and audit applications while reducing the friction for
More informationSetup Guide Access Manager 3.2 SP3
Setup Guide Access Manager 3.2 SP3 August 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE
More informationHP Software as a Service
HP Software as a Service Software Version: 6.1 Federated SSO Document Release Date: August 2013 Legal Notices Warranty The only warranties for HP products and services are set forth in the express warranty
More informationDeploying RSA ClearTrust with the FirePass controller
Deployment Guide Deploying RSA ClearTrust with the FirePass Controller Deploying RSA ClearTrust with the FirePass controller Welcome to the FirePass RSA ClearTrust Deployment Guide. This guide shows you
More informationHow to Implement Enterprise SAML SSO
How to Implement Enterprise SSO THE LEADER IN API AND CLOUD GATEWAY TECHNOLOGY How to Implement Enterprise SSO Introduction Security Assertion Markup Language, or, provides numerous The advantages and
More informationTIBCO Spotfire Platform IT Brief
Platform IT Brief This IT brief outlines features of the system: Communication security, load balancing and failover, authentication options, and recommended practices for licenses and access. It primarily
More informationSingle Sign-On Implementation Guide
Version 27.0: Spring 13 Single Sign-On Implementation Guide Last updated: February 1, 2013 Copyright 2000 2013 salesforce.com, inc. All rights reserved. Salesforce.com is a registered trademark of salesforce.com,
More informationAgenda. How to configure
dlaw@esri.com Agenda Strongly Recommend: Knowledge of ArcGIS Server and Portal for ArcGIS Security in the context of ArcGIS Server/Portal for ArcGIS Access Authentication Authorization: securing web services
More informationLeveraging SAML for Federated Single Sign-on:
Leveraging SAML for Federated Single Sign-on: Seamless Integration with Web-based Applications whether cloudbased, private, on-premise, or behind a firewall Single Sign-on Layer v.3.2-006 PistolStar, Inc.
More informationFor details about using automatic user provisioning with Salesforce, see Configuring user provisioning for Salesforce.
Chapter 41 Configuring Salesforce The following is an overview of how to configure the Salesforce.com application for singlesign on: 1 Prepare Salesforce for single sign-on: This involves the following:
More informationIBM SPSS Collaboration and Deployment Services Version 6 Release 0. Single Sign-On Services Developer's Guide
IBM SPSS Collaboration and Deployment Services Version 6 Release 0 Single Sign-On Services Developer's Guide Note Before using this information and the product it supports, read the information in Notices
More informationNetIQ Identity Manager Setup Guide
NetIQ Identity Manager Setup Guide July 2015 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE
More informationConfiguring Salesforce
Chapter 94 Configuring Salesforce The following is an overview of how to configure the Salesforce.com application for singlesign on: 1 Prepare Salesforce for single sign-on: This involves the following:
More informationPerceptive Experience Single Sign-On Solutions
Perceptive Experience Single Sign-On Solutions Technical Guide Version: 2.x Written by: Product Knowledge, R&D Date: January 2016 2016 Lexmark International Technology, S.A. All rights reserved. Lexmark
More informationMcAfee Cloud Identity Manager
NetSuite Cloud Connector Guide McAfee Cloud Identity Manager version 2.0 or later COPYRIGHT Copyright 2013 McAfee, Inc. All Rights Reserved. No part of this publication may be reproduced, transmitted,
More informationHow To Use Saml 2.0 Single Sign On With Qualysguard
QualysGuard SAML 2.0 Single Sign-On Technical Brief Introduction Qualys provides its customer the option to use SAML 2.0 Single Sign On (SSO) authentication with their QualysGuard subscription. When implemented,
More informationF-Secure Messaging Security Gateway. Deployment Guide
F-Secure Messaging Security Gateway Deployment Guide TOC F-Secure Messaging Security Gateway Contents Chapter 1: Deploying F-Secure Messaging Security Gateway...3 1.1 The typical product deployment model...4
More informationFairsail. Implementer. Single Sign-On with Fairsail and Microsoft Active Directory Federation Services 2.0. Version 1.92 FS-SSO-XXX-IG-201406--R001.
Fairsail Implementer Microsoft Active Directory Federation Services 2.0 Version 1.92 FS-SSO-XXX-IG-201406--R001.92 Fairsail 2014. All rights reserved. This document contains information proprietary to
More informationCisco ASA Adaptive Security Appliance Single Sign-On: Solution Brief
Guide Cisco ASA Adaptive Security Appliance Single Sign-On: Solution Brief October 2012 2012 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 21 Contents
More informationCA Single Sign-On r12.x (CA SiteMinder) Implementation Proven Professional Exam
CA Single Sign-On r12.x (CA SiteMinder) Implementation Proven Professional Exam (CAT-140) Version 1.4 - PROPRIETARY AND CONFIDENTIAL INFORMATION - These educational materials (hereinafter referred to as
More informationConfiguring. Moodle. Chapter 82
Chapter 82 Configuring Moodle The following is an overview of the steps required to configure the Moodle Web application for single sign-on (SSO) via SAML. Moodle offers SP-initiated SAML SSO only. 1 Prepare
More informationCA Adapter. Installation and Configuration Guide for Windows. r2.2.9
CA Adapter Installation and Configuration Guide for Windows r2.2.9 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation
More informationMONDESIR Eunice WEILL-TESSIER Pierre FEDERATED IDENTITY. ASR 2006/2007 Final Project. Supervisers: Maryline Maknavicius-Laurent, Guy Bernard
MONDESIR Eunice WEILL-TESSIER Pierre FEDERATED IDENTITY ASR 2006/2007 Final Project Supervisers: Maryline Maknavicius-Laurent, Guy Bernard Federated Identity Project topic Superviser: Maryline Maknavicius
More informationSAML Federated Identity at OASIS
International Telecommunication Union SAML Federated Identity at OASIS Hal Lockhart BEA Systems Geneva, 5 December 2006 SAML and the OASIS SSTC o SAML: Security Assertion Markup Language A framework for
More informationAuthentication and Single Sign On
Contents 1. Introduction 2. Fronter Authentication 2.1 Passwords in Fronter 2.2 Secure Sockets Layer 2.3 Fronter remote authentication 3. External authentication through remote LDAP 3.1 Regular LDAP authentication
More informationMcAfee Cloud Identity Manager
Salesforce Cloud Connector Guide McAfee Cloud Identity Manager version 1.1 or later COPYRIGHT Copyright 2013 McAfee, Inc. All Rights Reserved. No part of this publication may be reproduced, transmitted,
More informationNETASQ ACTIVE DIRECTORY INTEGRATION
NETASQ ACTIVE DIRECTORY INTEGRATION NETASQ ACTIVE DIRECTORY INTEGRATION RUNNING THE DIRECTORY CONFIGURATION WIZARD 2 VALIDATING LDAP CONNECTION 5 AUTHENTICATION SETTINGS 6 User authentication 6 Kerberos
More informationWebLogic Server 7.0 Single Sign-On: An Overview
WebLogic Server 7.0 Single Sign-On: An Overview Today, a growing number of applications are being made available over the Web. These applications are typically comprised of different components, each of
More informationSafewhere*Identify 3.4. Release Notes
Safewhere*Identify 3.4 Release Notes Safewhere*identify is a new kind of user identification and administration service providing for externalized and seamless authentication and authorization across organizations.
More informationSecure the Web: OpenSSO
Secure the Web: OpenSSO Sang Shin, Technology Architect Sun Microsystems, Inc. javapassion.com Pat Patterson, Principal Engineer Sun Microsystems, Inc. blogs.sun.com/superpat 1 Agenda Need for identity-based
More informationGetting Started with Single Sign-On
Getting Started with Single Sign-On I. Introduction NobleHour sets out to incentivize civic engagement by enabling users within companies, educational institutions, and organizations to conduct and coordinate
More informationStreamServe Persuasion SP5 StreamStudio
StreamServe Persuasion SP5 StreamStudio Administrator s Guide Rev B StreamServe Persuasion SP5 StreamStudio Administrator s Guide Rev B OPEN TEXT CORPORATION ALL RIGHTS RESERVED United States and other
More informationConfiguring EPM System 11.1.2.1 for SAML2-based Federation Services SSO
Configuring EPM System 11.1.2.1 for SAML2-based Federation Services SSO Scope... 2 Prerequisites Tasks... 2 Procedure... 2 Step 1: Configure EPM s WebLogic domain for SP Federation Services... 2 Step 2:
More informationCopyright Pivotal Software Inc, 2013-2015 1 of 10
Table of Contents Table of Contents Getting Started with Pivotal Single Sign-On Adding Users to a Single Sign-On Service Plan Administering Pivotal Single Sign-On Choosing an Application Type 1 2 5 7 10
More informationSingle Sign-on (SSO) technologies for the Domino Web Server
Single Sign-on (SSO) technologies for the Domino Web Server Jane Marcus December 7, 2011 2011 IBM Corporation Welcome Participant Passcode: 4297643 2011 IBM Corporation 2 Agenda USA Toll Free (866) 803-2145
More informationWorking with Indicee Elements
Working with Indicee Elements How to Embed Indicee in Your Product 2012 Indicee, Inc. All rights reserved. 1 Embed Indicee Elements into your Web Content 3 Single Sign-On (SSO) using SAML 3 Configure an
More informationA Standards-based Mobile Application IdM Architecture
A Standards-based Mobile Application IdM Architecture Abstract Mobile clients are an increasingly important channel for consumers accessing Web 2.0 and enterprise employees accessing on-premise and cloud-hosted
More informationPI Cloud Connect Overview
PI Cloud Connect Overview Version 1.0.8 Content Product Overview... 3 Sharing data with other corporations... 3 Sharing data within your company... 4 Architecture Overview... 5 PI Cloud Connect and PI
More informationSAML 2.0 Configurations at SAP NetWeaver AS ABAP and Microsoft ADFS
SAML 2.0 Configurations at SAP NetWeaver AS ABAP and Microsoft ADFS Applies to: SAP Gateway 2.0 Summary This guide describes how you install and configure SAML 2.0 on Microsoft ADFS server and SAP NetWeaver
More informationCopyright 2012, Oracle and/or its affiliates. All rights reserved.
1 OTM and SOA Mark Hagan Principal Software Engineer Oracle Product Development Content What is SOA? What is Web Services Security? Web Services Security in OTM Futures 3 PARADIGM 4 Content What is SOA?
More informationACTIVID APPLIANCE AND MICROSOFT AD FS
ACTIVID APPLIANCE AND MICROSOFT AD FS SAML 2.0 Channel Integration Handbook ActivID Appliance 7.2 July 2013 Released Document Version 1.0 hidglobal.com Table of Contents 1.0 Introduction...3 1.1 Scope
More informationAdvanced Administration
BlackBerry Enterprise Service 10 BlackBerry Device Service Version: 10.2 Advanced Administration Guide Published: 2014-09-10 SWD-20140909133530796 Contents 1 Introduction...11 About this guide...12 What
More informationSAML single sign-on configuration overview
Chapter 46 Configurin uring Drupal Configure the Drupal Web-SAML application profile in Cloud Manager to set up single sign-on via SAML with a Drupal-based web application. Configuration also specifies
More informationIntegrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies
Guideline Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies Product(s): IBM Cognos 8 BI Area of Interest: Security Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 2 Copyright
More information