Authorisation (aka Access Management) using Bloomfilters

While zooming along the highway on the way home the other day, I had an idea for making an authorisation service using Bloomfilters.

Let us assume you have a company website content management service, called ‘CMS’. Users can log in to the CMS and make changes to webpages or upload new content. The actual login (aka authentication) is handled by a separate system called A-Select which we do not have to concern ourselves with in this discussion.

The Access Management details needs to be maintained in a central place. So we have a service called A11n that runs on one machine, and the CMS service has to query the A11n service to find out if a user can perform some action.

The core of the idea is that the A11n service maintains the userids and roles which a userid is allowed to fullfill for various applications, and then makes the complete set of these available as an openly downloadable (via HTTP) Bloomfilter.

The CMS service (or any other application) periodically downloads the Bloomfilter file. When a user logs into the CMS, the CMS service does not need to contact the A11n server, it just has to check the userid+application+role entry in the Bloomfilter. If you get a definitive NO answer, you know that the user is not allowed to have a role. If there are multiple possible roles for a userid, the application server can check the existence of the userid+role for each role, and so the end result is a list of allowed roles.

What I like about this idea is that there is minimal crypto involved, no SSL necessary and the application servers can operate in a ‘disconnected’ mode from the centralised A11n server.

We have kicked the idea around a bit here internally at the TU Delft Library and have discussed the various tradeoffs with regards to choosing filter size and whether or not to include a shared secret between each application server and the A11n server to make it just slightly more difficult to guess the existence of roles for a given userid for privacy reasons.

A cursory Google on this idea did not reveal any immediate hits to others doing the same thing. I would appreciate hearing from others that are either doing the same thing, or can point out the glaring holes on why this might be a terribly bad idea.

About these ads
Explore posts in the same categories: Uncategorized

Tags: , , , , , , ,

You can comment below, or link to this permanent URL from your own site.

6 Comments on “Authorisation (aka Access Management) using Bloomfilters”


  1. Is a userid-AllowedRole an element here? If so then how would the A11n service handle authorization deletions when a person moves on or its otherwise deauthorized, since elements cannot be removed from Bloom filters? Would A11n get around this by generating and distributing new Bloomfilters whenever an authorization is no longer valid? That might (?) generate significant complexity and scheduling outside CMS.

    • pos.thum.us Says:

      The application service has to periodically fetch a ‘new’ Bloomfilter. So if a user is deleted or loses a role, there is a gap between the authorisation being revoked and the new Bloomfilter being fetched.

      One could choose how often the new filter is fetched, even going so far as to retrieving it every time a user logs in. A Bloomfilter to support 3000 users with a reasonably low false positive rate is around 8Kb, so not really gigantic to download.


  2. Thanks. OK no logistics problems then. I can’t see any “glaring holes on why this might be a terribly bad idea” and will be intrigued whether others do or will.

  3. Peter Says:

    Isn’t this all a bit to proprietary. Can’t your problem be solved with standard Shibboleth/SAML services, so you may extend this to a larger community ?

  4. pos.thum.us Says:

    We already use A-Select at the TU Delft for SSO (very much a NL standard, also used by the Dutch government), but this is only for the authentication part. Unfortunately there is no facility for us to conveniently do the authorisation part.

  5. pos.thum.us Says:

    And at a developers meeting yesterday we decided to not go with using a Bloomfilter, but to stick with having a central authorisation server which will return yes/no answers based on an userid+appid+role request hashed with a salt.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: