Propagating Authentication State to Oracle Single Sign-On in SP Mode

Planning Oracle Identity Federation Deployment 2-19 Figure 2–10 Authenticating with Oracle Single Sign-On in SP Mode The flow for authenticating a user at a peer provider with Oracle Single Sign-On is as follows: ■ The user is at the peer IdP Step 1. ■ The IdP redirects the user to Oracle Identity Federation as SP with an authentication assertion Steps 2,3. ■ Oracle Identity Federation processes the assertion, creates a local Oracle Identity Federation session, and forwards the user to the authentication module with the identification Step 4. ■ The authentication module redirects the user to Oracle Single Sign-On with the user identification Steps 5,6. ■ Oracle Single Sign-On creates a local authenticated session and grants access to the resource protected by mod_osso Steps 7,8.

2.3.6 HTTP Basic Authentication

Oracle Identity Federation can be configured to accept HTTP basic credentials without requiring an identity and access management system. This corresponds to using the JAAS authentication engine. Note: For more information about an environment where Oracle Identity Federation and Oracle Single Sign-On protect resources and either component can be the authentication mechanism, see Integrating with Oracle Identity Federation in Oracle Application Server Single Sign-On Administrators Guide. 2-20 Oracle Fusion Middleware Administrators Guide for Oracle Identity Federation

2.4 Data Repositories

This section describes installation requirements to enable Oracle Identity Federation to work with data stores. It contains these topics: ■ Federation Data Store ■ User Data Store ■ Session and Message Data Stores ■ Configuration Data Store

2.4.1 Federation Data Store

You must select a data repository for the persistent federation data store. Oracle Identity Federation works with industry-standard LDAP repositories including: ■ Oracle Internet Directory ■ Sun Java System Directory Server ■ Microsoft Active Directory ■ IBM Tivoli It also supports XML stores, databases, and a None option no repository for SAML and WS-Federation using non-opaque name identifiers such as e-mail address, X.509 DN, Kerberos, or Windows Name Identifier. Connection Information Collect the following information about the repository prior to installing Oracle Identity Federation: ■ The Connection URL space-delimited list of LDAP server URLs - hostname and port ■ The Bind DN This is the DN used by the Oracle Identity Federation server to connect to the LDAP server. For example: cn=fedid,dc=mycompany,dc=com ■ Password ■ The User Federation Record Context This is the node under which all federation records for this Oracle Identity Federation server will be stored. ■ The LDAP Container Object Class This is the type of User Federation Record Context that Oracle Identity Federation should use when creating the LDAP container, if it does not exist already. If that field is empty, its value will be set to applicationprocess. For Microsoft Active Directory this field has to be set, to container for example. The appropriate setting for this field depends on the User Federation Record Context being used. User Federation Record Context is described later in this section. Here are examples of the LDAP Container Object Class for different types of directory servers: – Oracle Internet Directory: empty