Four Responsibility Management Scenarios

A Policy Engine is not only an Entitlement Management System but also provides for functional evaluation of conditions that result in deterministic responsibilities for a given user or actor. In a talk at the GIDS Cloud Live 2020 series, Chandra Guntur talks about responsibility management, choices and entitlements. Read an excerpt below and watch the full talk on-demand for free.

What is responsibility management for an enterprise? What is the rationale for this? What are we trying to achieve? Let's start by looking at a few scenarios in this case. Alright, let's try to understand where responsibility management fits. Here are a few scenarios. I'm going to give you four scenarios. Here it goes.

Number one. Let's assume you have a service that requires to know if a user is a member of LDAP group, LDAP standing for Lightweight Directory Access Protocol. It's assumed that the service needs to know if a certain user is either a member of a group or not. Access is granted or denied based upon either membership or lack thereof, which is great, which is easy to solve. You can actually call the LDAP group, find that information out.

What if another service needs to know exactly the same information for a different user and different collateral? What if there are multiple other services that need this same information? What if there are people who either move out of the group, leave the company or join either the department, organization, or company? These are called movers, leavers and joiners, and we'll talk a lot about this as well. What could we do in this case? How do we handle this? This was scenario one.

Let's take a look at scenario two. Another service, Service M, needs to know if a user is a part of an enterprise email or active directory group, AD group. Once again, access may be granted or denied either based on membership or lack thereof.

How do you handle this? What if there are multiple services that require a similar feature with different users at different email or AD groups? Who manages the movers, leavers and joiners again? This is scenario two I present to you. I don't know how you solve the problem, but this is a scenario that is a problem statement.

Entitlement goes beyond something extremely static and can go into some amount of dynamism, as covered in these four cases.

The third scenario may be a bit more complex. What if you had some sort of a condition where you said "Hey, some user has to be a member of a given LDAP group, but not a member of another LDAP group, but it has a membership to an email group, but it's only allowed to request for an order in case of the procurement of an amount of $200,000, and also from an HR responsibility perspective, has at least two direct reports."?

These are conditions. I'm establishing some sort of a conditional check, with some amount of functionality in it, not just data, I'm actually writing some functional code here. What if the amounts are different in different cases? What if the HR responsibilities are different, etcetera, do come into play. Once again, the questions for such a complex request is: What if each request has different groups or amounts? What if there are services that have similar function with different values? How is this audited? Who's auditing this? Who manages, once again, the movers, leavers and joiners? Who's taking care of that? That was scenario three.

Now for scenario four. It's a very simplistic problem statement. It's based upon a user's individuality, which is for a given domain, for an application scope or for a given set of applications that is considered domain or an area where they operate in, for a given cost code or organization identifier. If you belong to a certain line of business, an organization, a company, a business unit, etcetera, there is a cost code identifier. For a given environment. Are you in production? Are you in development? Are you in QA, etcetera? For a given action. What are you trying to perform? You're trying to do an edit. You're trying to delete, create, update, etcetera. What is your operation? For a given resource. Are you operating on database X? Are you operating in one application Y? Are you operating on button X or Y, etcetera? It's something that can drive how you manage what the user is entitled to do.

Like This? Register for our Newsletter to Continue the Converstion

See Highlights of

Hear What Attendees Say

PWC Logo

“Once again Wurreka has knocked it out of the park with interesting speakers, engaging content and challenging ideas. No jetlag fog at all, which counts for how interesting the whole thing was."

Cybersecurity Lead, PwC

Intuit Logo

“Very much looking forward to next year. I will be keeping my eye out for the date so I can make sure I lock it in my calendar"

Software Engineering Specialist, Intuit

Groupon Logo

“Best conference I have ever been to with lots of insights and information on next generation technologies and those that are the need of the hour."

Software Architect, GroupOn

Hear What Speakers & Sponsors Say

Scot Davis

“Happy to meet everyone who came from near and far. Glad to know you've discovered some great lessons here, and glad you joined us for all the discoveries great and small."

Scott Davis, Web Architect & Principal Engineer, ThoughtWorks


“What a buzz! The events have been instrumental in bringing the whole software community together. There has been something for everyone from developers to architects to business to vendors. Thanks everyone!"

Voltaire Yap, Global Events Manager, Oracle Corp.

Venkat Subramaniam

“Wonderful set of conferences, well organized, fantastic speakers, and an amazingly interactive set of audience. Thanks for having me at the events!"

Dr. Venkat Subramaniam, Founder - Agile Developer Inc.