Monday 21 September 2009

Designing a Ruby Based Identity Management System

This is an itch I've wanted to scratch for a long time. I've worked with a variety of technologies that all to a greater or lesser extent make use of user identities. In fact, keeping track of all these identities is a major pain for most large companies and there are several identity management products out there.

These products generally have one thing in common. They are expensive. Very expensive. Novell Identity Manager is $25/person. Sun Identity Manager Suite is $75/person. If your customer has 10,000 workers, that is a lot of money, even before you the time to configure the product is factored in.

I think that it is possible to build a product in Ruby on Rails that has enough functionality for most requirements and do it in substantially less than 250 days (at $1,000 per day)

The generic, basic pattern of an identity manager solution is shown here.

Essentially there is a large database of people. The reason why it has it's own database in a modern outsourced company, people who have accounts on a company's computers could be employees of several different organizations. The goal is to get anybody who is allowed access to the organization's resources into that database. A major is to automate as much of this as possible.

The second point of the database is to ensure that the appropriate level of authorization, or sanction is supplied before user accounts are created on the target systems. Behind the scenes our people database needs to know which people can authorize which other people to have what type of accounts on what systems.

Another point about the people database is that it can be used to collect information from a number of different data sources. SAP HR may be the authority for a person's name and staff number, but the telephone system sets the user's phone number.

With this in mind, it is time to refine our diagram slightly. Systems, according to a set of rules may be either sources of data or sinks of of data.



Now the data sources are peers of the target systems and rules define the fact that they are the sources of data. We also have tables that contain replicas of the target data on each system. This is to allow us to query the information easily. We'll action user requests like "create a new account" immediately and also conduct batch syncs each night.

I'm going to cover this all in much more detail in later blog posts. I'll also put up some sample code on Git so you can play around and customize the code.

1 comment:

  1. I'm working on a similar project and would love to hear what you ended up doing. I realize it's been a number of years, but if you'd like to share any experiences or code, please drop me a line :-)

    ReplyDelete