Entitlement Management - Real World Examples

[aaronpk]

During today's call, we agreed we need to collect real-world examples of how current systems manage entitlements between apps and IdPs. Please use this thread to provide details on integrations you manage.

[2MarkMaguire]

To ensure we are speaking the same language, I will provide definitions for what I mean when I say Entitlement and Role (you will notice a bias to SailPoint - its where I started my IGA journey).

• Entitlement: A permission within an application.
• Examples: "groups" for AD, "roles" for Epic, "profiles" for Mainframe. All of these are types of Entitlements
• Roles: Entitlements that have been "bunched" together for abstraction purposes.
• Example: to use the payroll system, you need an AD "group" to login with SSO and separately need a "profile" within the payroll app to do your job. To manage, you create a Role in your IGA system containing both the AD group and Payroll profile. Now, within your IGA you just need to provision the role (which in turn provisions the group + profile), simplifying access requests and access reviews.

What I have seen in my career: Enterprise Access Management and Identity Governance tools are purchased to manage 100s of business applications. The first step after initial setup is "application onboarding." From an IGA perspective, this often looks like:

1. See if the app supports directory (AD/Okta/LDAP/OUD) integration. If it does, use directory accounts/groups to manage access (b/c an enterprise's directory is always connected to IGA during initial setup)
2. If directory integration is not an option, check if the app supports scim and connect with scim to manage the accounts/groups
3. If scim is not supported, check for APIs and write a WebServices connector to manage accounts/groups
4. If no APIs, check if there is a DB and write custom JDBC connector to manage accounts/groups
5. If no accessible db, see if you can extract a CSV of accounts/groups and manage them with manual tickets

Having seen hundreds of apps onboarded, my rough instincts are 60% of apps are managed through AD/SCIM/APIs, 20% though JDBC, 20% are legacy that need flat file connection.

What I want IPSIE to solve:

• The only reason that you have to write custom DB connectors / use CSV extracts is for applications which provide no interface for managing entitlements within the application
• For a App (aka relying party) to be IPSIE compliant, I think they must provide an interface for internal entitlement management. I really don't care how their internal access mode works as long as it can be managed centrally from an IAM tool.

[dhs-BI]

I don't have any recent experience to share on management of roles and groups. But I do have some questions that we should think about as we consider next steps:

• Roles, groups, etc. are relevant constructs to think about static assignment of permissions. How will IPSIE deal with a zero standing privilege model where the permissions are driven by an intersection of not just static entitlements, but runtime specific data? Specifically, I'm thinking about the recent Identity at the Center Podcast with Sean O'Dell where he discussed zero standing privilege.
• What is the intersection with AuthZen, if any? How should AuthZen influence our thinking? Conversely, how should we influence AuthZen?
• How do we deal with non-RBAC models such as ABAC and PBAC? What about systems that implement multiple models? For example, AWS IAM has a role based mechanism that is further tuned with ABAC.
• How would we deal with quorum based authorization?

[baboulebou]

This thread has been brought-up in our AuthZEN WG meeting. I'm not personally sure what you're trying to achieve with IPSIE and "entitlements" & authorization in general, but entitlements and authorization in general are better managed externally, in specialized systems, where you can determine exactly who can access what at any given time.

Therefore, rather than having RS/Apps expose APIs (or "ways") to modify their internal entitlements externally somehow, it should rather be the reverse: AuthZEN-enable those RS/RP's so they can ask authorization questions to external Policy Decision Points (PDPs). This will enable you to implement zero standing privileges and also be in line with Zero trust concepts. And finally it will make your governance much much easier.

There are many vendors in the authZ space that have already solved all the problems you list here, including the across-cloud "entitlements" management. They're all part of the AuthZEN WG btw. My advice then is to "just" ensure your add Authzen to your mix, and/or else, feel free to profile the Authzen spec...

[aaronpk]

@baboulebou I hope it is as simple as "just" adding AuthZen to the mix! Can you provide some real-world examples of how you are managing this today between SaaS apps and enterprise IdPs?

[baboulebou]

Well, unfortunately right now the worlds of the OAuth-type of "Authorization Servers" (likely what you refer to as IdPs) and authzen PDPs don't yet communicate much. I've been trying to bridge the gap but the effort its still nascent. I can nevertheless give you an example of such integration that we're implementing at Indykite (we're an AuthZ vendor, among other data things): Step-Up authentication, and integrating the OAuth Step-Up AuthN spec (RFC 9470) and Authzen.

The use-case is: only enable users to access resource X, say a medical record, if they have achieved a Lvl of Assurance (LOA) 2 or above (a strong MFA authentication method).

• User Alice goes to the Client App, and logs-in through the AS/IdP with passwrd. They get LOA=1 (access token claim: token.acr = 1).
• Through the client app, Alice tries to access her protected resource (her medical record).
• The medical record system (the RS) makes an AuthZEN call to an external PDP to see if the user is authorized to access the record: Subject = Alice, Action = read, Resource: Medical record 123 .
• The PDP checks its policies, one of the rules is: token.acr>=2 . This fails. The PDP therefore prepares a response as follows:
  • Response Header, from RFC 9470 -the PDP can "speak" RFC 9470 too :
    HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer error="insufficient_user_authentication", error_description="A different authentication level is required", acr_values="2 3"
  • Response Body, from AuthZEN :
    { "decision": false }
• The Client app gets the response, and as per RFC 9470 orchestrates a step-up AuthN with the IdP.
• Once the user gets a new token with token.acr=2, the client can make the initial request again.
• This time the PDP will grant access.

The important points here:

• the RS doesn't have the authorization policies.
• the Idp/AS doesn't either,
• most IdPs these days support RFC 9470
• everybody "speaks" standards
• you can ask all kinds of authorization questions to the PDP (e.g., "who can access record 123?", "what can Alice do?", full access audit trail, etc)
• you can centrally change and manage your policies without touching the RS or AS.
• none of this was using Roles.

[2MarkMaguire]

I like the concepts Dean and Alex bring up, particularly with "zero standing privilege," but I worry this is an area where existing legislation would limit technical adoption.

Many companies invest in Identity and Access Management (IAM) primarily to meet compliance requirements. For publicly traded companies, ensuring compliance with the Sarbanes-Oxley Act (SOX) is crucial. A key aspect of SOX compliance is conducting regular access reviews—typically on a biannual basis—of all applications that affect the production of financial documents.

To get even more specific, I have had numerous banking customers lately who all have the same problem: regulators are tightening requirements around IAM and giving "MRAs" to banks that cannot close-loop prove which accounts had access to which systems at which times. To pass audit, the auditors need to see, in a centralized location, all accounts and all of their entitlements.

While it is a good security idea, "zero standing privilege" would be an audit nightmare for SOX and financial services regulators. Telling an auditor, "no one has access until they request it, and then there is a runtime decision that gets made" would make this too much of a headache for most public companies. I think the value of IPSIE to a regulated company will be greatly diminished if we do not require apps to provide an interface that enables IAM tools manage their internal permissions.

[baboulebou]

" I think the value of IPSIE to a regulated company will be greatly diminished if we do not require apps to provide an interface that enables IAM tools manage their internal permissions."

Unfortunately Mark, this will be the opposite. Your central system with all access policies is a PDP. The Access policies are deterministic, zero standing privilege means you must add a policy to grant access. No policy, no access. So when a regulator comes, you can tell with confidence who has access to what.

Compare with your bank and its 100's of Apps (probably more like 1000's no? based on experience), and having to dig out entitlements from each one of them ... now that would be a nightmare!

Also the pb with IAM tools is that they don't enforce Authorization at runtime. Instead they do as you say, and use connectors to update target system's internal entitlements. And this in turn causes this access certification headache in the first place.

This is exactly the uphill battle the Authzen group has been fighting for a while. It would help everybody to externalize authorization to a central system (which can actually be distributed, anyway...).

[baboulebou]

Sorry, one last thought... I think an enterprise would need several authorization patterns. Where provisionning entitlements makes sense for Off-The-Shelf software like Salesforce, etc, the PEP/PDP/Authzen approach makes sense for in-house Apps or micro-services. So more likely than not you'll have all these patterns coexist, i.e., they're not exclusive. Which is also why you should consider AuthZen in your work too. My $0.02...

[Russell-Allen]

I've made multiple attempts to write about my entitlement experience from the application vendor perspective, and they keep turning into novellas. If I get something that's pithy, I'll add it then. In the meantime, I want to chime in on AuthZEN and its relation to IPSIE entitlement levels.

I'll be the first to state that my IAM experience is nascent compared to this audience. Most of my grey-haired wisdom is from designing and building server-side systems, mostly micro-service / SOA these days, and relatively evenly split between B2B and B2C. Security is, has, and will continue to be a foundational part of what I do.

My current venture involves a multi-tenant cloud platform. It federates identity via OIDC (bring your own IdP, or use ours; 1 to N per tenant.) It does not federate authorization. However, within the platform, there's a dedicated authorization service (dev in-house) that centralizes policy management. Every request to a service within the platform requires a bearer token from the auth service, and every resource server enforces access control based on the claims within that token. All external requests to the platform pass through a gateway service that validates the customer's bearer token (based on the tenant's permitted IdPs), maps the subject of that external token to our internal notion of identity, and then exchanges the external token for an internal token from the authorization service (after which the request is reverse proxied to the appropriate resource server.)

The more I read about AuthZEN (new to me), the more parallels I see to the platform I just described. Our auth service may be internal to the platform, but as far as all the resource servers know, it's an external policy decision point. Also, as a side effect of the platform's token exchange per external request, there's zero standing privilege. While that wasn't a design goal, it is evident in our ability to alter a user's permission in our auth service, and it has an immediate effect on all tokens (sessions) in the wild.

---

Two observations: domain language & time

First, I had the advantage of controlling both the auth service and resource services. Thus, when it came to defining the model used inside the auth service (the policy definition language) and defining the claim syntax/semantics (the assertion language) ... well, we all know how much easier it is when talking to oneself.

We've had a few customers ask about controlling authorization from their IdP, and the closest viable (to me) way of doing that would be through OIDC scopes mapped to the platform's internal notion of roles. Before you start nodding; That would be a very lossy mapping. The internal auth model defines policies in three parts, {action, identity, resources}, where resources is a filter expression that limits the set of applicable resource instances. I've yet to find a lingua franca that can be shoved into a scope string and maintain the expressiveness of the tuple I described.

Perhaps worse, even if there were such a language, I'm not sure I'd want to speak it. I presume it would require us to communicate a fine-grained, standardized description of our domain model and a similarly precise and complete catalog of actions. In that case, it feels like I'm giving away our IP. Even if we set that to the side, doesn't it feel like a 'smell' if an external system needs every detail before it can play its part? This PDP role and the resource server role seem pretty tightly coupled.

Having said that, maybe AuthZEN has a language model for PDP to resource servers that elegantly scales with need. My knowledge of it is as deep as Alex's comments, and I like being wrong when it means a better solution.

Second, let's talk time. I love the idea of "zero standing privilege." It fits perfectly in my zero-trust world. And when I step back and squint, making a PDP request every time looks a whole lot like a token refresh occurring every time. That makes me wonder if that's a naturally minimalized security model. After all, we started with certificates that are valid for years, then moved to tokens that are valid for hours or minutes, and now we're talking about something valid once. Does this mean I can stop thinking about IdP sent token revocation, universal logout, etc.?

Time has a dark side, though. Silly users like their requests answered in milliseconds, even if they expect an FBI background check on their bits. In the bespoke, internal platform auth service I can yell at the developer about performance, but an external PDP means both higher latency and a could-care-less attitude from the AI support bot.

[baboulebou]

Sorry didn't want to hijack this repo's issues... some quick answers for Russell...

• There are actually many PDP authorization models and languages. We use ReBAC and graphs to model authorization, others use purpose-built languages such as OPA Rego, ALFA, CEDAR, or several others actually. So the necessary expressiveness exists, no need for reinventing the wheel here. Since you're expressing yourself in "tuples", you may want to have a look at ReBAC systems ...?

• The pattern you describe: Authorization-by-token-scopes, is what I refer to as the "AuthZ at AuthN time": i.e, authorization (authZ) happens when the user essentially gets their token (authentication time, authN). It's fine, but its drawbacks are: token size limit, since Bearer tokens are passed as headers (how many scopes are you going to stuff in there?) + scope/claim freshness (what if the access policy changes while the access token has not expired yet? The user would be able to access the resource when they shouldn't anymore).

• The PEP-PDP-access-request-for-every-request model is in line with NIST's own recommendation and architecture for Zero trust (see https://www.nist.gov/publications/zero-trust-architecture) for example, and with ZT in general ("Never trust, always verify". I.e., don't trust your token either, it may not be fresh).

• There are a lot of ways to make modern PDPs performant, in the ms range, depending on vendors. They can be deployed as side-cars, distributed and scaled, they can cache data in embedded DBs, etc etc. Most vendors also typically perform various forms of caching to optimize performance. So response times are much less of an issue these days...