Management API Authentication Caching

This document is to start exploring the options to minimise the calls out to the security infrastructure so these calls are not required for every administrative operation.

Initially I am starting to explore two areas but this may expand if there are further suggestions.

Authentication Cache

This is an approach we have already used regularly in all AS releases as far back as I can remember, after a successful authentication the users username and password are stored in a cache, for every invocation to the server the users username and password are contained within the request and authentication is attempted - as a matching username and password are found in the cache the cached identity is used and the login modules are not called.

The design of the authentication cache being developed for AS7 is being discussed here: -

AS7:  Authentication Cache Design

If we were only going to be receiving the administrative requests on a single node then requiring the client to send the username and password with every request and make use of the authentication cache on the server should be sufficient for our needs, however once we add multiple nodes receiving requests independently other issues become apparent.

Assuming the request handling on the hosts are just a cut down / slave domain controller the security configuration can be inherited from the domain controller allowing for the same login modules and cache configuration on each node.

The first issue is how to really perform the authentication on these sub-nodes?

1. Send a request to the domain controller to see if it has already performed this authentication?
   • However the reason for these direct calls is for performance so the domain controller can be bypassed in this calls.
2. Perform the authentication on the hosts in exactly the same way as it would be performed on the domain controller?
   • This would lead to a performance hit on the initial query of each node as each node would need to authenticate independently.
   • This would also be a peak in load on the security infrastructure if the administrator contacts all nodes e.g. a script which loops to collect stats directly from each node.
   • Servers in a server group may be on hosts issolated from the rest of the network, access may only be possible to the domain controller.

One required feature of an authentication cache is cache invalidation, this is used to remove either an individual entry from the cache or to clear the whole cache - the end result is that once the entry is remove the authentication needs to be repeated for the cleared users the next time they connect.

• Users will have their roles reloaded by this so this will allow role modifications to be picked up.
• Users who's accounts have been disabled or have had their password reset will not be able to authenticate with the password used previously.

Having an independent authentication cache on each host then introduces it's own issues as cache invalidation needs to be considered.

• Would a cache invalidation operation be propagated to every node?
• Would an administrator need to call the invalidation on each node independently?

Authentication Token

The second option is to consider the user of an authentication token.

The user would invoke a login operation on the domain controller, the exact format would need to be designed further but in principal this would return a token which contains: -

• User identity
• Roles
• Created Time
• Expiration Time

This would be signed by the domain controller.

All subsequent requests would then contain this authentication token instead of the username and password.

Server side authentication would then verify the signature and check the token is between the created and expiration time and use the identity and roles from the token.

For distributed calls this would eliminate the need for non domain controller hosts to perform authentication either against the existing infrastructure or by calling the domain controller.

There is no need for an authentication cache as the token becomes the cache - however without a cache an alternative mechanism would be needed to cut a users access while there is a valid token for that user.

A black list could be maintained instead, if a user is to be forced to re-authenticate their identify could be added to the black list along with a time - any tokens created before that time will be rejected.  Objects will only need to remain in the blacklist as long as the token could be valid.

For this approach the structure and integrity of the token becomes critical for it's safe operation.

Out of Scope

This consideration is assuming confidentiality of the messages exchanged so this is not considering issues such as replay attacks as the token would not be publicly visible.