Kerberos application reference architecture
To make things easier for employees, many organizations have developed applications to use Kerberos. This may also be referred to as SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism or Kerberos over HTTPS), Windows Integrated Authentication, or Windows Desktop Authentication or Windows SSO.
This allows an employee logged into their Windows desktop easy access to an application without being prompted for their Active Directory (AD) credentials. Many other third party applications from both Microsoft and other vendors have also adapted their solutions to use Kerberos for authentication. While this has worked well for many years, users are much more mobile in today’s works and use a variety of devices, and locations and are not always are logged into a Windows device connected to an AD domain. Access Gatewaycan be used to bridge the gap between the modern mobile workforce and these applications built around Windows authentication.
In this scenario, Okta first logs the user in, possibly using the users AD credentials, or a MFA token, and then the user proxies through the Access Gateway to the application that is designed for Windows Kerberos authentication. Access Gateway reaches out to a Windows Kerberos cluster and through an established trust, can have the Windows Kerberos cluster create a token for the user, and then insert that token into the HTTP headers which is passed to the application. The result is the application sees the token, and identifies who the user is, and the application does not need to be changed when adding it behind Okta.
Additionally users can now access that application using non domain joined devices including mobile browsers. If the Access Gateway is deployed in the DMZ, and is publicly accessible, these users do not need to VPN into the network in order to access the application.
Approach
To deploy Access Gateway to secure applications in an environment described above, it is best to begin deployment of a base architecture and then add specific features as needed. This methodology will allow an organization to begin moving forward in an agile fashion and not become overly bogged down in requirements analysis.
Key steps in determining an overall architecture include:
- Identify how applications are to be integrated with Okta and Access Gateway. Typical integrations include:
- Single kerberos/Windows IIS application
- Header based
- SAML
- Others
- Identify how many users will access the applications and how often. This will help determine how many instances of Access Gateway are required, what number of load balancers are necessary and generally how the architecture components will be distributed.
- Identify which applications should be accessible through Access Gateway from the internet and which should require the user have access to the internal network. Typically this starts as a subset of applications, and expands over time.
- Identify and work with the AD team to get the proper system accounts and trusts / keytabs.
- Identify all AD infrastructure to determine the connections from Access Gateway to AD and the Windows Kerberos ticketing infrastructure.
Access Gateway Kerberos architectures
Access Gateway Kerberos installations can be deployed in any number of possible combinations. Common architecture are:
| Single Access Gateway instance | The simple Kerberos instance Access Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway. This architecture represents a baseline for development and testing. |
| Simple Kerberos cluster | The simple Kerberos cluster Access Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway. This architecture extends the single Kerberos instance by addingAccess Gateway cluster. |
| Kerberos cluster | The Kerberos cluster Access Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway and a redundant Kerberos cluster providing capacity and fault tolerance on the Kerberos side.. |
| Multiple Kerberos domain | The multiple Kerberos domain Access Gateway architecture represents a set of components required for Kerberos based authentication and authorization using Access Gateway and multiple Kerberos trusted domains. |
Architecture functional area breakdown
Architectures are broken down into the following functional areas:
| External internet | The external internet represents clients that access applications, as well as including your Okta Org. |
| DMZ | The DMZ houses an Access Gateway cluster, and associated components, to allow access to applications from the external internet. |
| Internal | The internal network houses the applications being protected by Access Gateway as well as other components required to make these applications widely available. |