Options for Windows Native Authentication with APEX

Purpose

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.

OID

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

SPNEGO

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.
http://spnego.sourceforge.net

MOD_AUTH_KERB

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 Tomcat to directly communicate with an Active Directory server.

CAS

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.

http://www.jasig.org/cas

WAFFLE

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)
http://dblock.github.io/waffle/

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.

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

    Marijan

  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?

    Thanks

  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:
    <filter-mapping>
    <filter-name>SpnegoHttpFilter</filter-name>
    <url-pattern>/f</url-pattern>
    </filter-mapping>

    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

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>