SharePoint and Identity Management–Part 3 of 3

In the last post I touched on a few things: Authentication and Authorization (AuthN and AuthZ), Kerberos Authentication, and Claims Based Authentication and how they all have a role in Identity Management.  In this final post of the series, I talk to Role Based Access Control (RBAC) .

Access Control

The rules that define what a user can access are essential to enumerate in a comprehensive Identity Management system.  In some higher security systems, the rules not only define WHAT a user can access, but also WHEN and sometimes from WHERE. Most of the time we are referring to something like an Access Control List (ACL); but using ACLs can become cumbersome when we are dealing with LOTS and LOTS of users and managing ACLs for LOTS of users (or groups) can create chaos—especially if there are conflicts.  This is where we want to talk about Role Based Access Control (RBAC).

Terminology

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

First, let’s set the vocabulary straight:

• Users—An entity that uses the system

• Roles—A job function within the context of an organization

• Permissions—Approval to perform an operation on one or more objects.

• Object—Can be many things; for example, an entry in a target system (such as an account), a network resource (a printer), an application (a procurement), a policy (password policies), and so on.

• Operations—Various and unbounded but including customer-defined workflow processes such as a password reset, the addition, modification, or removal (deletion) of user accounts, and specific data about them.

Users do many things and in a system such as SharePoint this can mean that users perform certain actions in one area, but different actions in other areas.  WHAT that person can do wherever they are doing it depends on the *ROLE* that person has in an organization.  Certain roles will have permissions granted to them.  You generally don’t want to have to give permissions to each object because then you would be returning to using ACLs which is a bad thing.

Below is a diagram of how RBAC could be used in a SharePoint implementation:

By assigning roles and giving the roles the access to do what they need wherever they are works much better than putting access on the objects and fretting about if someone needs access to it or not.