Single Sign On is basically an implementation mechanism or technology that allows customers of multiple browser applications to specify credentials once (at login typically) that are reused for that session for subsequent applications. This avoids logging on more than once. This aids in cross product navigation where a user logs onto one application and when transfer to another application avoid logging into that other product.
Single Sign On is not a product requirement it is an infrastructure requirement. Therefore there are infrastructure solutions available.
Typically there are two main styles of Single Sign On with different approaches for implementation.
The first style is best described as "Desktop" Single Sign-On. This is where you logon to your client machine (usually a windows based PC) and the credentials you used to logon to that machine are reused for ANY product used after authentication. Typically this is implemented using the Kerberos protocol and Simple and Protected Negotiate (SPNEGO) protocol. This is restricted to operating systems (typically Windows) where you perform the following:
- Setup the client machine browsers to accept and pass the credentials to the server. This sets the browser to read the kerberos credentials and pass them to the server.
- Setup the Microsoft Active Directory Services Network Domain Controller to accept Kerberos and pass onto the subsequent applications.
- Create a keytab file for Oracle WebLogic to use.
- Configure Oracle WebLogic Indentity Assertion Provider to specify that the keytab is to be used and that Kerberos is to be used for the Identity.
- Configure Oracle WebLogic to startup using the provider and Kerberos.
- Set the login preferences within OUAF to CLIENT-CERT to indicate the login is passed from somewhere else. This turns off our login screen.
As you can see the majority of the work is in Oracle WebLogic and is documented in Configuring Single Sign-On with Microsoft Clients.
The second style of is best described as "Browser" Single Sign-On. This typically means you login to the machine and then open the browser to logon. At this point as long as the browser is open, any subsequent application will reuse the credentials specified for the browser session. This is the style i implemented by SSO products such as Oracle Access Manager, Oracle Enterprise SSO and other SSO products (including third party ones). Typically implementing this involves the following:
- Setting Up Oracle Access Manager or the SSO product to your requirements. Oracle Access Manager supports lots of variations for SSO including Single Network Domain SSO, Multiple Network Domains, Application SSO, etc. This is all outlined in Introduction to Single Sign-On with Access Manager.
- Setting up Oracle WebLogic with Oracle Access Manager (this allows Oracle WebLogic to get the credentials from Oracle Access Manager). This is outined in Configuring Single Sign-On with Oracle Access Manager 11g.
- Set the login preferences within OUAF to CLIENT-CERT to indicate the login is passed from somewhere else. This turns off our login screen
Again, as you can see the majority of the work is in Oracle WebLogic and Oracle Access Manager.
Information about implementing Single Sign-On withour products (both styles) is contained in
- Single Sign On Integration for Oracle Utilities Application Framework based products (Doc Id: 799912.1) available from My Oracle Support.
- Oracle Identity Management Suite Integration with Oracle Utilities Application Framework based products (Doc Id: 1375600.1) available from My Oracle Support.
While the first style is lower cost typically, it is restricted to specific platforms that support Kerberos and SPNEGO. It is restricted also in flexibility, it passes the credentials from the client all the way to the server so they must match. Oracle Access Manager on the other hand is far more flexible supporting a wide range of architectures as well as including Access Control features, password control and user tracking features within WebGate. These features allow additional features to be implemented:
- Access Control - This allows for additional security rules to be implemented. For example, turning off part of a product during time periods. I have heard of customers using Oracle Access Manager to stop online payments from being accessible after business hours from a call center, due to customer specific payment processes being implemented. This augments the inbuilt security model available from Oracle Utilities Application Framework.
- User Tracking - Oracle Utilities Application Framework is stateless, therefore you can only see active users when they are actively running transactions, not when they are idle. WebGate has information about idle users as well as active users allowing for enhanced user tracking.
Whatever the style you choose to adopt, we have a flexible set of solutions to implement SSO. The only common element and the only step Oracle Utilities Application Framework is to change the J2EE login preference from the default FORM based to CLIENT-CERT.