Using SOA Expressway for Handling Kerberos in a B2B Environment

So a project manager walks up to you and tells you, “Hey, we just bought a company that creates purchasing order software. The PO system uses a Linux based implementation of Oracle Access Manager (OAM). We need to integrate this technology’s authentication mechanism with our implementation of Kerberos and Microsoft Active Directory. Unfortunately, their PO system doesn’t support any of the Windows Integrated Authentication solutions. We aren’t even sure if the system can handle SPNEGO. While OAM may handle SAML assertions, it definitely can’t deal with Kerberos tokens. Cost too much money to replace OAM. Our system must authenticate Kerberos tokens and then transform the authentication data into a format that the Oracle Access Manage can process.”

At which point you start panicking because you have never even heard of Kerberos or Oracle Access Manager. However, instead of having a heart attack, I’d like you to take a deep breath and consider whether Intel SOA Expressway, a XML Gateway that can transform and manipulate Kerberos authentication data, is the answer to your problems. But before I get there, let me outline the basics of Kerberos and the challenges it poises in a B2B environment.

What is Kerberos?

Kerberos is a trusted third-party authentication that was developed by the Massachusetts Institute of Technology long before the internet was invented (See rfc4120 for the Kerberos standard). In this protocol, clients and servers securely communicate with one another using shared keys, tickets, and session tokens. These security artifacts are created and managed by a Kerberos Key Distribution Center (KDC). A KDC is a trusted third party that consists of an Authentication Server (AS) and a Ticket Granting Server (TGT). The KDC has a database of secret keys for each endpoint identified in a particular network, which is only known to the client or server. Knowledge of this key proves an endpoint’s identity.

    1. User is authenticated by the AS. The AS sends ticketing granting ticket (TGT) to the client.

    1. User sends the TGT to the Ticket Granting Server.  The TGS uses the TGT to authenticate the client. Once authenticated, the TGS sends a service ticket to the user.

    1. User sends service ticket to the server, which the server uses to authenticate the client.

Doesn’t sound so bad, right? Well, when they say that devil is in the details, they weren’t kidding with Kerberos authentication.  This is a high level overview-it’s a lot more complicated in practice. There are over 8 different formats for Kerberos tokens, all of which you may need to support. The Kerberos protocol is not standardized and varies based on server implementation. And last but not least, there is no out of the box way to transform Kerberos authentication data into other formats.

Intel SOA Expressway Makes Kerberos Integration Simple

In theory, you could design a complicated, time intensive custom solution that integrates your Kerberos KDC with OAM. Or alternatively, you could use Intel SOAE as a XML gateway between OAM and your Kerberos system. The set up is simple. You just need to collect some basic information about the users that are being authenticated by Kerberos and then populate three Intel SOAE configuration pages with this data.

First, collect the following information:

    • Server Keytab: Obtain or create a Kerberos keytab for the service that the client seeks access to. A Kerberos keytab contains a list of principals and their secret keys. The principal is the unique name of the service or client.

    • Realm: Obtain the name of the realm that the client and server principals belong to.  A realm identifies the logical network served by a single Kerberos database and the Key Distribution Center.

Then, in Intel SOA Expressway:

    • Upload the server keytab.

    • Enter the realm in the Web Service Authentication policy.

    • Create an Authentication, Authorization, and Audit (AAA) policy that extracts the Kerberos token from a message request, authenticates the token, and then maps it to a different format (eg SAML)

And that’s it, you are done. Now Intel SOAE can authenticate any Kerberos token generated by your system using the following criteria.

    • Trusted realm generated the Kerberos token

    • Correct server principal is specified

    • Correct Kerberos version is used

    • Server key can decrypt authenticator

    • Checks ticket flags

    • Authenticator lifetime is valid

    • If checksum present, then verify it.

After the runtime authenticates the Kerberos token, it can transform the authenticated identity into a SAML assertion, an HTTP header, username and password, or an XML fragment. Basically, Intel SOA Expressway will simultaneously authenticate the Kerberos token and then map that to whatever format the Oracle Access manager can process.

For more complete information about compiler optimizations, see our Optimization Notice.