alt protocols

High Load Authentication Agent

Always Ask The Authentication Agent

Every group is represented by a bit in a bitvector. When publishing content, the Publisher creates a bitvector representing the groups that have access to the piece of content, encrypts it with a symmetric key shared with the Authentication Agent, and gives it to the Content Service. When a Consumer attempts to access content, the Content Service gives the Consumer this encrypted bitvector. The Consumer then turns around and (1) authenticates to the Authentication Agent and (2) gives the encrypted bitvector to the Authentication Agent. The Authentication Agent then decrypts the bitvector and checks if the Consumer is in one of the listed groups. If the Consumer is in one of the groups, the Authentication Agent signs a statement stating that the Consumer should be allowed to access the content (which the Consumer then presents to the Content Service).

Pros

• Simple
• Neither the Consumer nor the content service learn anything they don't need to know.

Cons

• High load on the authentication service: one signature, symmetric decrypt operation and communication round per piece of content.
• Trusts the authentication agent. Even worse, this tells the authentication whenever a user tries to access a piece of content for the first time.

Always Ask For Old Content

If the communication overhead of the scheme above proves to be too burdensome, the authentication agent could cache ACLs (group bitvectors) for recently published content and preemptively give the consumer statements authorizing the user to access this content.

Pros

• Less communication load on the Authentication Agent

Cons

• More complicated.
• Wasted work.

Behind The Consumer's Back

Another variation is to cut the consumer out of the loop. To do this, the Consumer authenticates with the Authentication Agent once per session and gets an identity token. When accessing content, the Consumer presents the identity token to this Content Service which turns around and presents both the ACL (encrypted bitvector) and the identity token to the Authentication Agent who can then respond with a simple yes or no (can the user access this content).

Pros

• Less communication.
• Less asymmetric crypto: While the connection between the Content Service and Authentication Agent needs to be authenticated, multiple requests can be multiplexed over the same connection.

Cons

• This forces the Content Service to make a third-party request in the background. That is, the Content Service will need to "pause" the Consumer request, fire off an authentication check in the background, and then resume the Consumer request at some future point in time. This is unlikely to play well with many web frameworks (other than node.js).

Trusted Content Server

Simple Version

Again, every group is represented by a bit in a bitvector. When publishing content, the publisher generates a bitvector representing the groups that have access to the content and uploads this in the clear to the Content Service.

Once per session, each Consumer will retrieve a signed (by the Producer), encrypted (with a symmetric key given to the Content Services by the Producer ahead of time) bitvector representing the groups to which the Consumer belongs. Additionally, this signed encrypted blob will contain a hash of the Consumers public key.

When accessing a piece of content, the Consumer will send this service-specific bitvector to the service along with proof that he or she controls the associated private key.

Pros

• Much less load on the authentication agent.

Cons

• The Content Services can track users and determine if two users are in the same group.