Oracle WebLogic Server Fails to Start

Configuring Single Sign-On using OracleAS SSO 10g 17-3 Figure 17–2 OSSO Identity Asserter Processing The first time a request for a protected resource arrives at the mid-tier Web server, the request is redirected to the 10g OracleAS Single Sign-On server, which requires user credentials For a certificate-based authentication, no login page is displayed. After the user has been successfully authenticated, all further requests from that user require only that the user identity be asserted by the OSSO Identity Asserter before the population of a JAAS Subject takes place. The Subject is consumed by the downstream applications. For example, suppose you have an application residing on an Oracle WebLogic Server that is front-ended with the Oracle HTTP Server. The application is protected using resource mappings in the mod_osso configuration. This case is described in the following process overview. Process overview: OSSO Identity Asserter 1. The user requests a protected application.

2. The Oracle HTTP Server intercepts the request and processes it using mod_osso to

check for an existing, valid Oracle HTTP Server cookie.

3. If there is no valid Oracle HTTP Server cookie, mod_osso redirects to the OracleAS

SSO Server, which contacts the directory during authentication.

4. After successful authentication mod_osso decrypts the encrypted user identity

populated by the OSSO server and sets the headers with user attributes.

5. mod_weblogic completes further processing and redirects the request to the

Oracle WebLogic Server.

6. The WebLogic security layer invokes providers depending on their settings and

the order specified. For example: the security layer invokes the: ■ Identity Asserter, which makes the identity assertion based on retrieved tokens ■ Oracle Internet Directory Authenticator OID Authenticator, which populates the Subject with necessary Principals See Also: Consumption of Headers with OSSO Identity Asserter 17-4 Oracle Fusion Middleware Application Security Guide 7. A response is sent to the user through the Oracle HTTP Server, and access to the application is granted.

17.1.1.3 Consumption of Headers with OSSO Identity Asserter

This topic describes the headers sent by Oracle HTTP Server and the tokens set in the header and the headers consumed by the OSSO Identity Asserter. If the application needs to use the JAAS subject, configure OSSO Identity Asserter. Table 17–1 provides the list of headers set by Oracle HTTP Server mod_osso and mod_weblogic. An application whose logic consumes the JAAS subject for identifying user information, should be configured to use the OSSO Identity Asserter. which uses the OracleAS SSO token type set in bold in the table Proxy-Remote-User. The OSSO Identity Asserter looks for the Proxy-Remote-User header and asserts the user’s identity. The follow up OID Authenticator populates the JAAS subject. Applications that do not require the JAAS subject for identifying user information, can read the headers directly using the request.getHeader API. Such applications are free to read any header they need. Headers with user info are Osso-User-Dn, Osso-User-Guid, and Proxy-Remote-User.

17.1.2 New Users of the OSSO Identity Asserter

The new OracleAS Single Sign-On solution includes the OSSO Identity Asserter, one of the two new Authentication Providers for the Oracle WebLogic Server. To have your application use the OSSO solution, you need the components described in the following task. Task overview: Deploying and configuring the OSSO Identity Asserter 1. Install the following components: a. OracleAS Single Sign-On Server 10g 10g OSSO server Table 17–1 Headers Sent by Oracle HTTP Server Attribute Sample Value Description Cookie OHS-Stads42.us.oracle.com:7777=....... Cookies Osso-User-Guid 4F4E3D2BF4BFE250E040548CE9816D7E GUID of the authenticated user Osso-User-Dn cn=orcladmin,cn=users, dc=us,dc=oracle,dc=com DN of the authenticated user Osso-Subscriber DEFAULT COMPANY Subscriber name Osso-Subscriber-Dn dc=us,dc=oracle,dc=com Base DN of the subscriber Osso-Subscriber-Guid 4F4E3D2BF410E250E040548CE9816D7E GUID of the subscriber Proxy-Remote-User ORCLADMIN The authenticated user Proxy-Auth-Type Basic SSO Authentication type Note: If you already have components installed and set up, you do not need more. You can skip any steps that do not apply to your deployment.