This is a short article providing an easy, but perhaps a not so obvious way, to use Novell Access Manager (NAM) for Single Sign-On (SSO) access to the Oracle E-Business Suite (OEBS). OEBS is used as the example, but the same SSO enabling strategy used here can be applied to other web applications as well. This article assumes that the reader has a basic understanding of NAM concepts and administration. Since users normally access OEBS through a web form, one is naturally tempted to use a NAM Form Fill policy for SSO. This is a fine approach but this article offers a more simple approach using an Identity Injection Policy.

Typically Identity Injection policy based SSO is used to populate the standard HTTP Basic Authentication header mechanism with the user's credentials, but Basic Authentication is not supported by OEBS (at least not in the version of OEBS I was testing against). But OEBS will accept the user's credentials sent via the Query String. Without NAM involved, to authenticate to OEBS as in the following:

http://<OEBS server>:<port>/OA_HTML/fndvald.jsp?username=<username>&password=<password>

NAM uses this Query String method by simply substituting the user's username and password values in the above URL using an Identity Injection policy.

But first you need to define a reverse proxy and published DNS name for OEBS (e.g. ebiz.sat2.corp.com). There is nothing special to this configuration. Simply gather the correct web server address(s) and define your proxy. In my case, and most likely yours, HTTPS from the NAM Access Gateway and OEBS is required. This is an important security concern. Unless the communication between the Access Gateway and the OEBS web server(s) is protected by firewall rules, it will be very important to use HTTPS when NAM communicates with OEBS. Otherwise the communication stream including the user's credentials in the Query String sent to OEBS will be available as clear text to network packet sniffers. To enable HTTPS, first enable HTTPS on the Identity Server, then enable it between the browser and the Access Gateway. Next import the OEBS web server certificate (and chain if applicable) using the NAM configuration wizard to enable SSL communication between the NAM Access Gateway and OEBS web server(s). With all these in place we now have full end-to-end (browser to OEBS) SSL protected communication. The result is depicted in the sample NAM screen shot below:

Click to view.

Next configure two protected resource paths in the reverse proxy configuration. One specifically for the login URL (/OA_NTML/fnvald.jsp) to which we will apply our Identity Injection Policy and another for all the other OEBS web server paths (/OA_HTML/*). Both protected resource paths are also assigned an authentication contract as depicted in the sample below:

Click to view.

Now define an Identity Injection policy (e.g. ebiz_sso_ii) that injects the user's credentials into the Query String and assign it to the login path (/OA_HTML/fnvald.jsp) depicted above. In my case I injected the user's LDAP username and password using the Credential Profile as depicted below:

Click to view.

Apply/enable your policy to your OEBS login protected resource path (/OA_HTML/fndvald.jsp) as depicted below:

Click to view.

Update your server configuration and test using your NAM protected resource URL for OEBS login. Following my example above, the login URL is:

http://ebiz.sat2.corp.com/OA_HTML/fnvald.jsp

Summary

There are many ways to facilitate SSO using NAM: SAML, WS-Federation, Form Fill policies, and Identity Injection policies, and other strategies. Sometimes the most obvious mechanism, like in this OEBS example a Form Fill policy, is not always the easiest way to do the job. I usually first try using an Identity Injection policy with standard HTTP Basic Authentication even when It is not obvious that the web application supports HTTP Basic Authentication. The only obvious sign that your web app supports Basic Authentication is when it does not use an HTML form so when you go to its URL a very non-descriptive pop-up dialog box appears, but the lack of this dialog box pop-up is not definitive. One such example is the Novell Identity Manager User Application. Although Basic Authentication is supported, it also provides a form-based login because it is nicer to look at and more informative for the user. But with SSO, these things are not important since the user will never see the form anyway! Basic Authentication through an Identity Injection policy takes only seconds to configure and test, so worth a try. Your web app may also allows the use of non-standard/custom HTTP headers or the Query String that the web application can recognize and use for authentication as in our case with OEBS. Unfortunately there is no easy way to ferret out these capabilities other than talking with the vendor/author, scouring the app's documentation or searching the internet.