One of the more challenging aspects of integration work is dealing with various security protocols. This holds true both as a consumer of a secured service and as a producer of a service that must enforce the security protocol.
Recently, I have found myself assisting a number of customers with various aspects of Kerberos security. For those not familiar with Kerberos, it is, very simply, a network authentication protocol designed to provide secret-key cryptography-based authentication for client/server apps. Kerberos requires great attention to detail with the settings on for both clients and servers to the extent that configuration parameters are case sensitive, even in Windows.
Now, MuleSoft is involved with Kerberos in two areas and in the following capacity:
- Acting as a server: applying Security Policies to Mule hosted APIs to enforce Kerberos authentication
- Acting as a consumer: connecting to Kerberos enforced services, typically leveraging one of the many MuleSoft connectors.
Today I want to discuss the first use case, that of the application of Kerberos Security Policies to Mule hosted APIs.
In theory, Kerberos can be deployed as a set of services on any arbitrary OS, but in practice, I have only seen it widely used as part of a Windows environment––as Kerberos is the underlying mechanism used in ADFS.
So with that in mind, let’s get a few terms out of the way. Firstly the “Ticket,” this is an encrypted identity that is not only used to identify you as a user, but also the service you are calling. Tickets are obtained from a KDC or Key Distribution Center, in Windows the Domain Controller(s) provide the KDC service. Anytime a configuration parameter asks for the KDC, think Domain Controller for the value.
Similarly, Kerberos has the concept of a Realm, the Realm contains the set of services that can be accessed, in Windows, we refer to this as the Domain. Kerberos Realms are always fully qualified, so the fully qualified Windows Domain name should be used for the Realm value. One other term that you should be familiar with is that of SPN or “Service Principal Name,” this is used as an identifier for users and services. For services the naming convention is:
<service type>/<fully qualified server name>@<REALM>
For example: HTTP/myserver1.some.com@SOME.COM
The above example is the type of SPN that we typically use for the Mule runtime when it is hosting APIs in a Windows ADFS environment.
The Kerberos framework provides a mechanism for authentication, but what is missing is the ability to ensure a Kerberos Tickets are used in HTTP based communications, the foundation for REST APIs. Enter the SPNEGO mechanism which – when used in the “HTTP Negotiate” header in an HTTP request – allows a Kerberos Ticket to be submitted to an HTTP service.
Now we are getting somewhere, with these components we can see how a service could be deployed into a Windows Domain with a policy that works with the “HTTP Negotiate” header and authenticates users against ADFS. This is exactly how it works with a Mule runtime hosting an API that needs to be secured via Kerberos.
MuleSoft provides a policy for authenticating users against a Kerberos Realm, it deals with the “HTTP Negotiate” header requesting a Ticket from the incoming client, validates the Ticket, and also performs an LDAP group lookup to ensure the user is in a group allowed to call the API. You can find more information on Github.
API Proxy
A further use of Mule in an API-led context is that of running an API proxy in front of a Kerberos secured service, whether Mule hosted or a custom service. This is where things get tricky, let’s refer to the API implementation as our “backend” and the API Proxy as our “proxy.”
Kerberos Tickets contain information on the calling user as well as the target service; in a proxy use case, the client only knows about the proxy. If the original Kerberos token was passed straight through the proxy to the backed, it would ultimately fail authentication as the ticket will not match.
This particular style of use case has a solution, known as delegation. Kerberos delegation allows the proxy to obtain a new Ticket on behalf of the original user to call the backend.
MuleSoft can provide an API policy that performs the authentication and delegation. The setup required for a delegation is more complex and prone to error than a regular Kerberos authentication use case.
MuleSoft has implemented delegation based policies for customers across various industries, and our services team are always on hand to help you through the process.
