IONA Artix Security Primer MS-Compatible Kerberos Support

Objective: To provide a mechanism to Artix Server implementations to determine the user-id of the client making a request, leveraging the Kerberos implementation within Microsoft's Active Directory (A.D.), primarily for .NET based clients. (NOTE: This is client-only authentication, not mutual authentication.)

Microsoft Security integration benefits: Client users of the system need only provide their identity once, by logging into a Windows Domain. There is no need to provide one's identity to the client .NET application. The only information required is the identity of the A.D. account assigned to the Artix Security Service instance. The Assignment is carried out through provision of a keytab file by A.D. administrators for the account used by this process.

Kerberos by definition requires the client to know the identity of the server with which it is communicating. Active Directory creates a token when requested to do so by the client. This token is manufactured such that only the server can interpret it. Note that in this case, the server is the IONA Security Framework process as opposed to a specific Artix server instance within the cluster.

For this example (based on a customer example) IONA's Artix implementation includes a location service that provides endpoints for a specific type of server to clients on demand. This service is not secured.

Once the client secures an endpoint from the Artix Location service, it then makes contact with a Session Management service living within each process within the server cluster. The key purpose of the session manager is to provide the client with a transient unique session key. This key is passed to the server in a custom SOAP header. It also provides an enumeration of endpoints within this process for the various business logic interfaces hosted therein. This provides the client with the confidence that the server instance is devoted to him and therefore a stateful conversation can take place. This session manager interface is also not secured.

When the client has a valid session id, it attempts to make an invocation on the business logic interface. It is at this point that the Artix Security filter on the server will intercept incoming requests. It takes the Kerberos token from the header, together with the user-id sent in the clear, within an additional SOAP header, and forwards them to the IONA Security Framework Service (ISF). This process utilizes the GSSAPI Kerberos support within jdk1.4.x to authenticate the request. Authentication is deemed successful if the plaintext user-id matches the one within the Kerberos token. If the authentication fails, the security interceptor within the Artix server rejects the request throwing back a SOAP fault with an Authentication Failure message. The business logic implementation will not even know a request was attempted. If the authentication is successful then the security interceptor within the Artix server will transparently allow the request to continue.

If the security interceptor (working with the ISF process) authenticates the request, it then continues on to the session Endpoint Manager plugin/filter. This is a message interceptor that looks for a valid session-id within a SOAP header for the request. Pending this session-id being present and valid, the request is transparently passed through to the business logic interface on which it wishes to make a request.

At this point when the business logic implementation is servicing a request, it can be confident about the following:

  1. That the requester has a valid session-id
  2. That the plaintext user-id that's easily accessible within the server implementation code as part of the incoming SOAP request header, is authentic.
  3. Transmission of the client user-id within a plaintext soap header is not only for server programming convenience. The Kerberos specification talks about clients, servers and trusted 3rd parties. Strictly speaking, as far as Kerberos is concerned, the server is actually the ISF process. That way clients can use a generic server-user-id when creating Kerberos tokens, IONA can leverage JDK support for GSSAPI and servers can be transparently added to the cluster without the need to modify any of the security configuration.

For optimal performance, there should be an instance of the IONA Security Framework service (ISF) running on each host for its cluster of Artix server processes. Kerberos requires a per-request validation of the token (to protect against record and playback attacks) so each request on each Artix server within the cluster on that host will result in a loopback call to the ISF process. On a positive note however, the ISF process will not have to make any remote calls in order to authenticate the request because it's keytab file contains the codes required to interpret the Kerberos token.

SERVER HOST

.NET CLIENT MICROSOFT ACTIVE DIRECTORY

.NET CLIENT MICROSOFT ACTIVE DIRECTORY

Procedures;

  1. .NET Client Requests a Session Managed Endpoint from the Artix Locator
  2. .NET Client Requests a Session from the returned Session Manager Service
  3. .NET Client Requests URLs for Biz Logic Services with Leased Endpoint
  4. .NET Client requests a Kerberos token from Microsoft Active Directory
  5. .NET Client invokes on biz logic interface with Session Id from Session Manager, Kerberos token from A.D. and plaintext user-id within SOAP headers.
  6. .NET Client periodically renews the lease on the Session Manager interface or lease will eventually expire, invalidating the accepted session id.

If a request comes in with an invalid session id, the business logic service implementation is not even made aware that a request came in. The Endpoint Manager message interceptor/filter throws a SOAP fault with �invalid session id� in a similar fashion to the security filter dealing with failed authentication efforts.

The configuration of Artix Clusters with regard to Kerberos Security is primarily centered on the ISF service having a valid �keytab� file corresponding to an account within Active Directory that the clients are aware of. It's imperative that clients know the user-id associated with an endpoint that is going to be authenticating them. Therefore at this point, there should be at most one Active Directory account used behind a given Artix Locator instance.

Keytab file : A file generated on the Active Directory system, using the �ktpass' utility. An application in possession of a keytab file for a given account knows that accounts password/secret.

IN DEVELOPER CENTER...

Related Content

Need More Info?

Feel free to reach us by phone or email anytime of the day.

> View Phone Numbers
> Contact Us Form

Contact Sales

For pricing and license information please contact a sales representative in your region:
AMER, EMEA or APAC