Since several months we are working on designs and implementations of identity management (IdM), a discipline increasing security and UX in the IT landscape of organizations.

IdM is quite an interesting area, you need to touch and use a big set of technologies and a bunch of already existing security standards. And you need to talk to many people in an organization.

Here are some tips and rules you should follow, independent of products you may use.

Note: We are talking here about role based access control (RBAC), which is the most prevalent authorization model. Other models can easily connect to this design.

So let’s start

No matter where your central point of structure or truth is located, either an application or more common, a directory service, the design of this area is the key.

A recent talk I did in a customer project: Directory Structure

Implementing organizational hierarchies in IT systems usually gives you headache and a lot of work, since those hierarchies tend to change frequently in large organizations. But we don’t like frequent changes of our structure and security base. So we need a clever design here: allow the data to change, not the structure.

Whatever comes, in IT we always start with a layer model…

Our model or how we see this world

  • Layer one: identities (also called persons, users)
  • Layer two: organizational units (teams, departments, etc.)
  • Layer three: organizational roles (enterprise roles)
  • Layer four: application specific roles (groups)

Where the first one is a flat list of identities, the second one usually will be needed to implement a certain form of hierarchy and membership.

Talking in LDAP: use “member of” for memberships. It’s easy to browse up the hierarchy. Optionally you may implement a second list “members” for comfortably browsing down the hierarchy, in case the directory server does not automatically offer this. You should be aware this is data redundancy, but often very useful.

The third layer is a flat list without inheritance, each role describing a certain general role in your organization. Keep this one more business/organizational related and don’t stick it to used applications or products.

The last one is a long, flat list of already existing, application defined roles or groups. Those may be technical or business roles, it doesn’t matter since the applications are the master of those data. They need to maintain the mapping to their low-level application permissions.

What’s an application?

Well every kind of system we deal with is an application. It may be your CRM system, an trouble-ticket system, an physical access control, and your intranet system. And yes, your file server and mail server are applications too.

Wow, a lot of data here!

That’s true, but we won’t enter it manually. See below…

So, how to use this?

Everything we do then is to create and maintain relations between elements of those layers.

You won’t map from layer one (identities) directly to layer four (app-roles), this is like shooting yourself in the foot. Abstraction means in our case to link via layer three, our organization roles.

Please serve yourself

A self-service application may be used to create new relations or end-date existing ones. In general that’s a good idea, already medium sized organizations deal with a huge set of entries and relations.

Changes on those relations can be provisioned directly or as an approval workflow. You can even use both methods, depending on who captures this change.

Request and approval permissions should be mapped again to enterprise roles or in that special case to the owner of the involved objects (in LDAP represented with the owner field).

An example

We decided to create a new organizational role for finance controllers, since their responsibilities are already too distinct from finance agents, the role we used up to now. Our ERP team has already implemented a new ERP role erp-controller, covering their needs in a better way.

We will create this new organizational role finance controller and then request to map this role to the ERP application role erp-controller. This request shall be approved by the responsible team, in this case the ERP security team.

We know this, because the organizational role security-erp is the owner of application role erp-controller (like for all other ERP application roles). Three persons are currently in security-erp, and we hope not all of them are currently on vacation. An email has been sent to notify them we need their approval.

I hope you get the point…

Who is feeding this system?

Identities and organizational units

Changes on persons and organizational groups (layer one and two) and relations between those should come from the HR team. In case there is an HR system in place, an interface to this system is the way to go.

Creation of new persons (new employees) and retirements are straight forward to implement. Moving a person from one department to another means deprovision the direct relations of the person and assign it to the new team. Roles defined via the team will already be available to the person, direct assignments to certain enterprise roles need to be requested.

Application roles

For large implementations an automatically exchange of app roles to the individual applications is worth the effort. Usually the way from the app to the IDM system is the more important one.

How are those rules enforced?

Nowadays almost all applications support directory services by LDAP integration. It’s important to use this integration for authentication and authorization.

Authentication

Authentication can be done by an LDAP call (ldapbind, ldapcompare) or offering single sign on (SSO). There are several options you can use for SSO. A common way for access within an intranet (or using VPN) is to implement Kerberos.

If you want to support access coming from Internet you need another technology, e.g. own implementation with a common cookie, OpenID, or other central authentication services.

Authorization

Systems using the directory service will retrieve the application role the user has been assigned to.

For legacy systems not offering a directory integration you need to provision this data (user and assigned app role). Data exchange in both ways gives you the knowledge what rules are really in place (hacked into the end system).

Huh, this post was getting longer than I thought.

Let me know your experience or opinion…