Authentication Service

This article is do describe the new authentication service being added to AS7 to support security context proagation and connection re-authentication.  Until the component is complete this article should be considered work in progress.

Due to the dependencies involved this service is developed as a stand alone project that will be subsequently integrated into the application server, most likely the security subsystem.

Project Structure

The project (will) provide(s) the following: -

Authentication Service

This is the core service running within the application server, this service is associated with all supported security realms and handles the authentication requests and the providing of the authenticated identities internally.

Server API

Fer secured services looking to use the identities an API will be provided for direct access to the service.  A permissions check on the SecurityManager (if any) will be performed to verify the call should be allowed, user code must not be able to interact with the service unless that permission is granted.

The server API may also provide an API that can be mapped to domain management operations to allow the state of the authentication service and the connection to be managed.

Internal Client API

On the client side calls will be made to the remote authentication service using the defined protocol over Remoting - to simplify the use of the protocol this will be wrapped by an API - however this is most likely not the API that the clients will use to manage the associated identities.

Reporting the internal reasons for authentication failure to a client is generally bad - however despite this there are a lot of users asking that error messages can be sent to client.  By default we should keep the errors server side only but do allow propagation to be switched on.

Public Client API

This is the API that will be used by client applications to manipulate the identities associated with the current connection, use cases are being identified and the resulting API will be to solve those use cases.

The current discussions are along the lines that this will re-introduce the concept of a SecurityContext on the client side - this SecurityContext will allow the association of many identities that can then be selected for the actual invocations.

Versioned Remoting Protocol

The protocol itself will live in it's own module, client and server side of the protocol will be written in parallel to ensure they remain in synch. 

Remoting Protocol

The protocol is a versioned protocol, this means that the client and server will negotiate to use the most up to date protocol that both sides understand.  The only exception to this is that both sides will also allow for versions to be excluded either through configuration, their APIs or by system properties - the reason for this is that if a vulnerability or bug is found in a version of the protocol it can be excluded - this is applicable even for older versions as you may not want a client to force the use of an older version with a known issue.

The versioning will also indicate if the protocol version is from a Final release or an intermediate release, backwards compatibility is only maintained within a protocol once it has reached the final state.

Security Permissions and Policies

The ability to both manipulate the client side SecurityContexts and the ability to access the service AND any associations with the Remoting Connection will be strictly protected using Permissions and the Java SecurityManager.

The development must output documented sample security policies that demonatrate how to grant the required permissions, the AS integration will also build on this to demonstrate the policy required server side.

As a stand alone project the testsuite of the project should also include full testing with a security manager and the sample policies.

Application Server Integration

Configuration

Items to be configured within the application server: -

The service itself is a generic service, initially this is being used for EJB invocations however this can potentially be used for all services so the configuration of the service needs to be central - I would suggest within the security subsystem.

The service will only be installed if the configuration is present.

• Available Realms
• Advertise Realms?  Should clients be able to request a list of available realms.
• SASL Configuration - the capabilities of the realms guide this but additional overrides may be needed.
• Caching configuration - validity periods? limit per connection?
• Error propagation.

EJB Container

The EJB container will need to be modified so that if a request is received with a token ID then the Server API should be used to obtain that identity and run the request as that identity.

Where a call is being made to a remote server there needs to be some form of switch to enable propagating the identity to the remote server, this most likely needs an API option and a configuration option to enable it.

EJB Clients

The EJB client side in conjunction with the public client API will need to support the client side management and switching of identities and the passing of the selected token with the method invocation.

Security Realms

The security realms now need to be updated as to support this feature a user authenticating to the server needs to be able request an alternative id for the authorization decisions.