Identity Management Platform Role-Based Security

Role-based security is one of the most important parts of an identity management platform.  The post’s purpose is to explain why role-based security is important.  I’ll give some examples of how it manifests practically.  Role-based security is the ability to give different users of your application different responsibilities based on their role in your organization.  This is especially important for web applications where different people should have different views in their browser appropriate for their needs.

Why is Role-Based Security Important?

Good role-based security allows an identity management platform to meet the unique needs of distinct types of users.  A ton of functionality in your identity or access management solution can actually be damaging without granular security.  For example, if you give a user the ability to clone directory users you might not want them to be able to clone users everywhere– just in a small part of your directory.  Certainly you probably wouldn’t want to give that user (or any user?) the ability to delete objects outright.

Without role-based safeguards the risks and liability are enormous.  Enabling users to create problems accidently is as bad as giving someone access to create mischief intentionally.

Examples of Role-Based Security in Identity and Access Management Systems

Listing every instance where fine-grained security is important is too exhaustive for this article.  Some examples might be helpful, however.  These examples can serve as things to look for around security if you’re evaluating an Identity or Access Management system.  At the top of the chain in the security hierarchy is the super user.  The super user is the administrator who has the ability to define roles for all other users.  Super users of your application can configure these types of settings.

• Allowing end-users to see appropriate navigation menus based on who they are
• Allowing end-users to have different directory provisioning and deprovisioning forms with different fields and options appropriately
• Giving end-users the ability to search on different kinds of directory objects possibility limiting what they can see by OU(s)
• Allowing end-users to see certain attributes of certain objects and edit others in a completely configurable way:  a manager might be able to edit attributes of her subordinates records for example
• Controlling what end-users can see or edit about their own records
• Controlling who can see and manage which groups
• In workflow, controlling who can approve which actions (in addition to who can perform which actions):  you might have a manager who can approve only some of their employee’s actions
• In a password management solution, different types of users must go through different factors of authentication to reset or change their password or unlock their accounts

Auditing

In addition to fine-grained control over application access an identity and access management system should have built-in auditing safeguards.  For example, it could be helpful to receive a push notification if your “domain admins” group in Active Directory changes in any way.  That can give some peace of mind that an unauthorized user hasn’t hijacked your directory.

Who are your Users?

Some identity management tools out in the wild only support two types of users:  administrators and help desk users.  Their pricing even supports this model by charging by the number of help desk users.   End users are all individuals.  The organization’s need should dictate their treatment.  This is recognized by complete identity management platforms such as Web Active Directory’s PeoplePlatform.  Any user can benefit from an identity management system, for example even if it’s using it as a read-only corporate directory.