Oracle Access Manager SSO with WNA (Kerberos)- Authentication Flow

In this blog post we will briefly discuss about Kerberos first then will see how workflow of Oracle Access Manager SSO with WNA works.

The Kerberos Authentication Service was developed by the MIT. It’s a protocol for network authentication. It was developed to enable network applications to securely identify their peers. In Kerberos basically client proves its identity by presenting to the server a ticket. Kerberos uses secret-key cryptography for communication. The good part of this protocol is that no password travels over the network. Other important factors are strong cryptography and third-party ticket authorization. Kerberos authentication is currently the default authorization technology used by Microsoft Windows. Kerberos plays an important role of SSO as well. The server where all this Kerberos magic takes place is called KDC (Key Distribution Center). KDC is a group of three main components:

• A principals database of secret keys for all the users or services
• An authentication server who does the initial authentication and issues ticket-granting tickets (TGT) for users.
• A ticket granting server (TGS) who issues the service tickets that are based on the TGT.

Authentication flow in case of Kerberos :-

1. The client sends an authentication request that includes the date + time to the Kerberos KDC. (Encrypted part of the request is encrypted with the client’s password.)
2. KDC in Active Directory (Domain Controller) validates that the user by decrypting the message. It can decrypt the message because key is used in encryption was user’s password. KDC can access the password stored in Database.
3. KDC generates a ticket (TGT) and sends to client. Client stores the TGT for future requests. (KDC encrypts the TGT with key which is not shared with Client and only used internally)
4. Next time onwards if client has to access a resource then it sends the TGT to TGS with SPN of the resource.
5. TGS Sends a valid session key to client for access. Client uses this session key to access the resource.

Above mentioned flow gives you a high level view of Kerberos Authentication steps. We will discuss now how Kerberos can be used in SSO provided by Oracle Access Manager services.
Single sign-on (SSO) is a process that gives users a privilege to access protected resources with one time authentication. Oracle Access Manager has Kerberos Authentication module as well. This plug-in is used while configuring Access Manager for Windows Native Authentication. WNA (Windows native authentication) is an authentication mechanism in which users (windows login)are validated against Kerberos.

Lets discuss about workflow when a user access Oracle SSO-WNA protected application. It is as follows -

1. The user logs in to a Desktop which is on AD Domain (Kerberos Realm) and opens up IE browser to access a protected application.
2. WebGate intercepts the client’s request for protected resource and checks for OAMAuthnCookie. If available then resource can be accessed, if not Webgate will check with OAM Server for authentication.
3. In case of WNA protected resource OAM will ask webgate that it needs Kerberos token for authentication. Webgate will send the request back to browser
4. Browser will send the Kerberos token (Browser has obtained Kerberos session ticket from the KDC) back to the webgate then it will go to OAM Access Server.
5. OAM Access Server validates the token. OAM has a keytab details (SPN info )and it can perform validation with KDC for token. (In this step SPNEGO comes into picture. SPNEGO is pseudo mechanism” used by client-server software to negotiate the choice of security technology. It gets the information about KDC from krb5.conf file placed on server)
6. If verification is successful then application access will be provided.

Note:

• Keytab files are commonly used to allow scripts to automatically authenticate using Kerberos, without requiring human interaction or access to password stored in a plain-text file. For more details: https://kb.iu.edu/d/aumh
• User Principal ( user@XYZ.COM)is the fully qualified username of a user in a domain. Server principal ( HTTP/box.xyz.com@XYZ.COM)is also the same thing but it is for a system instead of a user.

I had only one intention with this blogpost: To explain Kerberos authentication workflow in a very simple and easy steps when using with Oracle Access Manager. I hope it will help. Next blogpost I will explain how it can be configured in Oracle access Manager. Thanks.