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. 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:

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:

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:

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

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


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.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

Leave a Comment

  • mday2 says:

    I would be very wary of using the Query String to give SSO. A couple of reasons:

    1. The Query string information is in the GET request which means that any log file at the AG, Oracle box or intervening component will also log the user’s credentials in clear text.

    2. The target app may redirect the user’s request whilst preserving the query string info. As a result, the injected credentials may suddenly become viewable at the user’s browser which would be a major concern. A Referrer header may also include the query string credentials which is another place that the credentials may be leaked from.

    So usign SSL does not necessarily protect leakage of credentials.

    Will the app accept the credentials if you use custom header parameters called “username” and “password” or whatever instead of the query string? Not that I would particularly recommend it but at least the most dangerous potential information leakage mentioned above would be avoided.

    Also, with this approach, there may be a problem if the target application password is changed, expired, or locked and passwords etc. aren’t synched to the NAM user store. At least with FormFill you have the flexibility to script different behavior.

By: pmckeith
Aug 19, 2010
10:18 am
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Sentinel Supported Troubleshooting Workflow