Integrating Oracle Access Manager with Kerberos authentication with fallback to an HTML form

Seems like it's the month of Kerberos.

We often see customers wanting authenticate users to Oracle Access Manager (OAM) with Kerberos, and fall back to HTML forms if the Kerberos authentication fails. There's an easy way to set this up, but it's not obvious how to do it.

I'm just going to describe the flow here, but that should be enough to help you figure out how to do the actual knob turning yourself. If you run into trouble feel free to ask a question here.

1. user accesses http://somemachine.mydomain.com/protected/
   
2. OAM redirects the user to http://trustedmachine.mydomain.com/oamauthenticator/
   
3. on trustedmachine the virtual directory /oamauthenticator/ is protected by IIS' built in Kerberos functionality, and only Kerberos. In other words you should uncheck the Basic, Digest and Anonymous checkboxes in the IIS console.
   If the user's workstation is in the domain and they are signed in then their identity will be passed to IIS via Kerberos. If the user's worksation is not in the domain or something goes wrong they will be presented with the 401 error page (see below)
   
4. the OAM WebGate will consume the identity from IIS and pass that identity to the Access Server
   
5. the OAM Access Server will search LDAP for the user
   
6. once the user's OAM session has been established they will be redirected back to http://somemachine.mydomain.com/protected/ along with the ObSSO cookie.
   

alternative flow for workstations not in a domain or if Kerberos fails:
In step 3 if the Kerberos authentication fails IIS will send the HTML file configured as the 401 page

You can create a plain HTML page that

• contains a conventional OAM login form - prompting the user for their username and password.
  
• submits to an URL on trustedmachine
  
• that URL will be associated with a conventional OAM HTML forms login authentication scheme
  

When the user fills in the form and hits submit:

1. the credentials will be passed to the Access Server
   
2. the Access Server will search LDAP for the user and bind to the directory to authenticate them
   
3. if the credentials are correct the user will get an OAM session cookie
   
4. the user will be redirected back to the original resource as in the normal flow above.
   

The only real trick here is using the custom error page in IIS. Remember that you have to use a plain HTML file for that file - you can't use an ASP/ASPX. That also means that you have to do anything dynamic in JavaScript.

Update: I fleshed this out some more in a newer post.

CAPTCHA vs. Strong Authentication (with OAAM)

A colleague was asked by a customer for a comparison between using a CAPTCHA solution and Oracle Adaptive Access Manager (OAAM). As people try to understand the role of CAPTCHA and different “advanced” authentication solutions in general, this type of question is actually pretty common.

The most common CAPTCHA solutions involve a user picking a series of alphanumeric characters (often distorted or partially obfuscated) out of a generated image and entering the characters along with the rest of the input.

CAPTCHA injects this specific type of challenge-response flow into an authentication (or other web input) to ensure that the input is really coming from a human and not a computer. It is often used with authentication, self-registration, and other application specific interactions like concert ticket buying systems to prevent various denial of service attacks and other mass input abuses of the system.

While CAPTCHA (arguably) does a good job at making sure that a user really is human, that is all that it does. It does nothing to make an actual user authentic stronger. It does nothing to prevent phishing, nothing to detect or prevent fraud, nothing to mitigate stolen passwords. The credentials being supplied in a username and password form with CAPTCHA is still just a username and password.

On the other hand, strong authentication is about adding additional “stronger” credentials into the authentication to go along with a username and password. Usually this means incorporating something a user has like an ATM card, hardware authentication token, or software token or alternatively something a user knows like a series of personal questions that other people aren’t likely to know.

Along with strong authentication often come secure input technologies like personalized pictures and phrases, keypads, and sliders that are utilized to prevent phishing and stolen passwords in general.

OAAM is an exceptionally powerful yet easy to use and deploy strong authentication and fraud prevention solution. You can read more about its capabilities here and by reading the white paper found here. On a personal note, I think OAAM is a very strong product and a leader in the space.

While there is overlap between OAAM (or strong auth in general) and CAPTCHA technologies in that a strong auth solution can help ensure that an application is interacting with a human, there is still a conceivable need for both.

Strong authentication is for well… authentication and requires that a user exist and that additional authentication factors be provisioned prior to the authentication. This makes it inappropriate for registration and other interactions where the user may be anonymous. On the other hand CAPTCHA can be used without knowing specifically who a user is.

It may also be appropriate to use CAPTCHA in an interaction that occurs at some point after (strong) authentication to ensure that a human is still in control of the client system.