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 the 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 implements 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.
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)
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.
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.