Identity & Access Management (IAM) is built on workflows -- a workflow is the sequence of actions that actually decide who a user is, what they can do, and to what can they do it.  I like Gartner's definition: "IAM ensures the right people get the right access to the right resources at the right time, enabling the right business outcomes."

All of those "right this" or "right that" is where it gets complicated.  Who can do what, how do you determine who has the rights to undertake a particular action in a workflow?  The RBAC model relies on roles (and ABAC to a lesser extent); based on what we know about a user's identity (department, title, location, business function, etc), we determine what their role is.  We then assign permissions to roles rather than to individual users.

Here's a great example: a doctor can access a patient's medical records.  Easy...we have two roles, doctor and patient.  Let's make it match the real world though, a doctor can only access a patient's medical records if that patient is under that doctor's care.  We can't make that many roles, so we add a run-time ABAC check to see if that particular patient is under that doctor's care and only grant access if that is true.  We do this with only two roles but use ABAC for finer granularity.  We have a whitepaper on the RBAC and ABAC hybrid model, please download it.

So, that's how we define who has access.  But more often than not, there is an approval layer in the workflow.  We know that an admin role can create a new user but might need an HR approval before it happens.  A user can update their own phone number but their manager needs to approve it.  A user can join a distribution list but the group owners need to approve it.  It's a simple business control but can get complex.

And that's where Rights Based Approval Routing (RBAR) comes in.  When designing the workflow around users joining groups, you can't define a single role as the approver because there are many (IT admins, the group owner, your COO for example).  What you do is put in a "go for approval" shape and let RBAR handle it.

The RBAR approval shape basically says, "does the user requesting access have the right to do this?"  If the answer is yes, then, bam, it's approved.  If the answer is no, RBAR asks, "well then who does?" and goes to get that approval.

Let's use our group example, the user requests to join the party planning committee distribution group.  RBAR notes that the user is not an owner or an admin so it first attempts to send an approval request to the owners.  If there are owners, that approval message is in their hands.  If there are no owners (you remember from The Office how often that committee changed), then RBAR looks up who else can do it...IT admins and the COO...and sends it to them for approval.

Without the IAM architect having to do any of the work for this multi-faceted approval methodology, RBAR has made a robust and easy method of implementing Role Based Access Control (RBAC) and getting more out of less resources.  Check out a more technical explanation of how RBAR fits into IAM workflow.