Options for Windows Native Authentication with APEX


The Single Sign On (SSO) / Windows Native Authentication (WNA) / Windows Network automatic login concept was something I championed when I was working at my previous employer. The idea was to utilize the internal network logins and provide access to web applications with the current Windows domain user. Because all of the network access was through the Active Directory domain, we wanted to leverage the Windows PC logins. We could always do custom login solutions – prompting for user and password – but the goal was automatic login (no password prompts) similar to what you would get with SharePoint or other Microsoft aware solutions.
Here is an outline of different methods we used to accomplish this goal. This is intended to be a starting point as the technical details to implement will vary based on environment and individual needs.


One of the Oracle subscribed methods to accomplish automatic logins is Oracle Internet Directory (OID) and the native -SSO-Partner Application- option in APEX. By syncing the Active Directory to OID, OID can have a trust relationship back to the main AD server. This is a complex setup process as the sync can be one way or two way. It requires a fair amount of installation and configuration between the two systems. This worked fine for us, until there was a change to OID that needed a patch, or AD attributes would change. Depending on how complex the system architecture group decides to make the OID installation will also impact the ease of use. This worked, but had a very monolithic dependency we had to deal with.
APEX 4.2 Docs


When the APEX listener was in early adopter, we started looking at simpler ways of getting SSO to work. Because we no longer needed to use mod_plsql, there were JAVA options to push the authentication out to the web server. The first simplification was to make the web server easier to maintain. With the help of a Unix administrator, we started using the HTTP server that was part of our Unix operating system. Tomcat is a standard option that can be implemented as a Solaris service with very little configuration required. To achieve this, we implemented the SPNEGO/Kerberos key concept of identity. A key tab file (keytab) is created that enables the trust relationship with active directory. The authentication is implemented using uses a simple FILTER on the apex listener path. This creates the requirement: Any call to the APEX listener is an authenticated user. This concept is not specific to Tomcat. SPNEGO can work on many J2EE web server, and is documented as part of several web server SSO implementations such as Weblogic.

The draw back for the “you must have a windows login” was if we ever used the APEX Listener as a service. Any service calls would have to be authenticated. Because of this, we made a second “non-sso” version of the listener on the same web server. Applications that required authentication would still prompt, but we could then also serve up public pages without authentication using the “http://host:port/apex-nonsso/” path.


Using a similar method of Kerberos keys directly with Tomcat has been written up and published by Niels de Bruijn – Member of MT AGHis paper has been published in Slideshare.  It includes detailed instructions on how to configure the Apache web server using “mod_auth_kerb” to directly communicate with an Active Directory server.


As time went on, our colleagues in the Engineering ERP department wanted to do the Windows Native also, but they were all hard core JAVA developers. They had the requirement to put additional logic on the SPNEGO option and allow it to switch between multiple domains. The goal was similar to SPNEGO (with actual underpinnings), but with an ability to put logic into a “fail over” concept. Using the JASIG CAS libraries, the team was able to implement a fall back authentication screen that they could default to if desired that let them pick the domain they wished to log into. (One was Active Directory, one was internal product specific account LDAP). The result was an attempt to log in automatically, but with an option to log out that would prompt to a login window (outside of APEX) enforced by the web server. This had the additional switching options that the team required.



The last way we implemented the automatic login was using WAFFLE. It requires a windows server that gives it access to the Active Directory space without the need for a Kerberos Key specifically made for the sign on. You still get to use Tomcat / Glassfish with the APEX listener, just simpler to configure and deploy in a windows VM environment. This was done for a small project, but proved very effective with less red tape because you do not need the Kerberos key created specifically for authentication. (it is built into the Windows Server)

Header Variable

All these methods (with the exception of OID) utilize the HTTP Header to pass the authenticated user. With the introduction of the authentication “Header Variable” option in APEX 4 it makes it very easy to consume and use this value. We implemented the technique before that was available, so we simply had a custom authentication routine that would read the value and continue on if it was acceptable. There was a quick re-direct past the login page, and the user would be able to continue with their Windows user name as their user.

The concept is simply described by me as: push the authentication back to the web server, then let APEX trust the web server authentication.

APEX Header Auth

These by no means are the only options. These are simply some of the ways that I have experienced and had success with. Comment below with any additions you have had success with.

11 thoughts on “Options for Windows Native Authentication with APEX

  1. Hello

    We are working on oracle apex sso. We installed waffle and tomcat. The problem is that for owa_util.get_cgi_env(‘REMOTE_USER’) we get “APEX”

    Have you done this and how?

    Thnak for your help.


  2. My best suggestion is to unit test Waffle. There are how-to’s on their site to test the integration. Use their Authenticator Demo included. At the end of the day, APEX should get the same result as their Demo. When we accomplished the setup, we had to make sure the server was running as a domain user and not a local machine user. They needed to have domain trust.

  3. Very useful write-up, thanks! One question about the SPNEGO option. You write “Because of this, we made a second “non-sso” version of the listener on the same web server”.

    I am not sure I understand how to implement this. I assume you copied $CATALINA_HOME/webapps/apex.war to $CATALINA_HOME/webapps/apex-public.war and used java -jar to configure it. But as per the instructions in http://spnego.sourceforge.net/spnego_tomcat.html all the configuration appears to be “global” i.e. it would apply to *all* Tomcat webapps. So how can I configure /apex to use SPNEGO but not /apex-public?

    Also, by cloning the ORDS webapp, I guess if there are any Oracle configuration changes (e.g. change to Oracle listener, password change for APEX_PUBLIC_USER), it would have to be done in both webapps, right?


  4. The point on security is this:
    In Tomcat – to you apply a filter – say the Spenego filter to your web app, you would add the Spnego filter (per their documentation) to your WEB.xml, then add a filter to your WEB.xml like such:

    This means that any references to http://host:port/apex/f… will enforce the SPENEGO authentication.

    Well, what if you want to have PUBLIC pages? If I am on an internal corporate network, this may not be an issue.
    In some cases, we used web service style calls, and didn’t want the authentication. In that case, we simply setup a second listener that did not enforce authentication.
    The applications that needed it would either re-direct or fail authentication.
    Public applications would use the other listener that did not require authentication.

  5. Can you please clarify on how you setup a second listener for public pages? The documentation for the url-pattern parameter http://docs.roguewave.com/hydraexpress/3.5.0/html/rwsfservletug/4-3.html indicates that it does not match the context path so we can’t setup another ORDS instance called public.war since the /f would match both of them. I thought /apex/* would match the authenticated one while /public/* would match the public webapp but it doesn’t appear to work that way.

    Help? Thanks

  6. Hi,

    I’ve been using Jasons script to utilize the NTLM SSO on APEX and it has been working perfectly until I had to upgrade from Oracle database 10g to 12c and OHS from 10 to 12.
    All of the sudden it’s not working (on first entry it says not authorized) but after F5 (refresh) it enters.
    Since I couldn’t fix that, I installed ORDS and Tomcat8 and switched from OHS to ORDS/Tomcat8 variant. This error stopped so now the script works but I am looking out for other way to authenticate my domain users.
    Since I don’t have direct access to domain controller, I’ve tried Waffle.
    Waffle works on the provided demo page. its correctly defines domain\username and displays it on its page.
    However, I cannot find a way to implement it into ORDS.

    You mentioned, on your web page (http://wphilltech.com/options-for-windows-native-authentication-with-apex/) that you managed to make it work on one small project.
    Any and all help or info you can provide would be most welcomed!

    Thank you in advance!


  7. Igor,

    When using Waffle – it works like a lot of the other trusted setups.
    You can use the “Header Variable” to read the value that the process authenticated.

    Some methods allow you to configure what is reported.
    To see all of the header values that your service provides, try this:
    – Create a PL/SQL region
    – Add the function owa_util.print_cgi_env;
    View the page and you should see a full list of the environment values which should include your user account provided by Waffle.

  8. Hi Tim

    Thanks for this article.
    I just tried the Waffle sample in tomcat, and it seems to wok fine here, setting the REMOTE_USER.

    The format of the REMOTE_USER is: \, which I assume will propagate into the APP_USER session variable in APEX ?

    Have you found a way to only have the windows username in the REMOTE_USER variable (without the domain) ?


  9. When we used that method, we put in a “Post Authentication” function that would format the user and strip any values we didn’t want.
    Another option would be to set some values for “Display User Name” or “User ID” session values that could also be used by applications.
    This way – the domain user name would be in a session value that was NOT the one that would be seen. You have many options at this point.

  10. hi,

    I’m tying to implement SSO Kerberos on APEX deployed on weblogic. My environment has BI Publisher standalone installation. So I want to leverage its weblogic to have APEX on the same host. SSO Kerberos has been already configured and tested successfully for BI Publisher. I will like to implement SSO for APEX as well so whenever a user access APEX will not have enter the credentials. I’ve deployed the ords.war and i.war files to weblogic and they started successfully. Then I try to modify the web.xml and weblogic.xml files of the ords.war file and redeploy it, but it fails. Is there another configuration step I’m missing? maybe on the APEX side?



Leave a Reply

Your email address will not be published. Required fields are marked *