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...

[Russell-Allen]

Excellent info and references. Thank you for those.

The authorization service I described fits the PDP role perfectly, as do the resource servers as PEPs. Our syntax for defining the resources of a policy is relationship-based, too, and conceptually equivalent to ReBAC.

Our system starts to diverge with AuthZen's decision that the PEP sends all facts to the PDP, and the PDP responds yes/no. We have the equivalent of the PEP sending just the identity in the request and the PDP responding with a condensed policy set that applies to that identity.

For practical reasons, I favor sending the PEP a policy set from which it can make decisions because there's often more than one to be made. For example, creating a resource referencing another requires a create action on the first and a read on the other.

I still want the PEP to get the policy set at the start of processing every request so we don't have to worry about a stale state. It is equally important not to read the PDP more than once for one logical request. If the PEP had to make a PDP request per auth check encountered during the request, I could contrive a race condition that violates auth policies.

It's also been my experience that having the PEP more involved in and aware of the authorization process leads to better auth. In the AWS Cedar intro, they described this as "ergonomics." I worry that sending all the facts and getting a boolean response makes all of the auth a black box to the developer, which may increase human error.

Footnote: You're right; our use of bearer tokens to transport the "condensed policy set" resulted in header size issues. Moving it to a PDP response body addresses that.

[baboulebou]

Hi Russell, So the mechanism you describe is akin to what we call partial searches, and it's work underway right now within the working group. AuthZen is not finished yet :). Feel free to join the WG sessions! Cheers, ./\.

…

On Sun, Feb 16, 2025, 8:55 a.m. Russell Allen ***@***.***> wrote: Excellent info and references. Thank you for those. The authorization service I described fits the PDP role perfectly, as do the resource servers as PEPs. Our syntax for defining the resources of a policy is relationship-based, too, and conceptually equivalent to ReBAC. Our system starts to diverge with AuthZen's decision that the PEP sends all facts to the PDP, and the PDP responds yes/no. We have the *equivalent* of the PEP sending just the identity in the request and the PDP responding with a condensed policy set that applies to that identity. For practical reasons, I favor sending the PEP a policy set from which it can make decisions because there's often more than one to be made. For example, creating a resource referencing another requires a create action on the first and a read on the other. I still want the PEP to get the policy set at the start of processing every request so we don't have to worry about a stale state. It is equally important not to read the PDP more than once for one logical request. If the PEP had to make a PDP request per auth check encountered during the request, I could contrive a race condition that violates auth policies. It's also been my experience that having the PEP more involved in and aware of the authorization process leads to better auth. In the AWS Cedar intro, they described this as "ergonomics." I worry that sending all the facts and getting a boolean response makes all of the auth a black box to the developer, which may increase human error. Footnote: You're right; our use of bearer tokens to transport the "condensed policy set" resulted in header size issues. Moving it to a PDP response body addresses that. — Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCDAWU347O7Z5ZQKMZCX632QC7HVAVCNFSM6AAAAABW5YEKQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRRGUZDENRSGU> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: Russell-Allen]*Russell-Allen* left a comment (openid/ipsie#51) <#51 (comment)> Excellent info and references. Thank you for those. The authorization service I described fits the PDP role perfectly, as do the resource servers as PEPs. Our syntax for defining the resources of a policy is relationship-based, too, and conceptually equivalent to ReBAC. Our system starts to diverge with AuthZen's decision that the PEP sends all facts to the PDP, and the PDP responds yes/no. We have the *equivalent* of the PEP sending just the identity in the request and the PDP responding with a condensed policy set that applies to that identity. For practical reasons, I favor sending the PEP a policy set from which it can make decisions because there's often more than one to be made. For example, creating a resource referencing another requires a create action on the first and a read on the other. I still want the PEP to get the policy set at the start of processing every request so we don't have to worry about a stale state. It is equally important not to read the PDP more than once for one logical request. If the PEP had to make a PDP request per auth check encountered during the request, I could contrive a race condition that violates auth policies. It's also been my experience that having the PEP more involved in and aware of the authorization process leads to better auth. In the AWS Cedar intro, they described this as "ergonomics." I worry that sending all the facts and getting a boolean response makes all of the auth a black box to the developer, which may increase human error. Footnote: You're right; our use of bearer tokens to transport the "condensed policy set" resulted in header size issues. Moving it to a PDP response body addresses that. — Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCDAWU347O7Z5ZQKMZCX632QC7HVAVCNFSM6AAAAABW5YEKQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRRGUZDENRSGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Russell-Allen]

I want to add another 'experience' to this thread, this one involving an external entitlement integration.

The abovementioned platform manages an otherwise independent system with its own users and authorization model. One of the platform's features is provisioning users into this managed system. There's a scheduled AD (LDAP) and Azure AD approach as well as a SCIM-based solution.

In the AD/AAD case, the platform customer selects which users to provision based on dir group membership. User entitlements can be set based on group or attribute, but the expressiveness is limited to a 1-to-1 static mapping.

The SCIM solution gives our customers more flexibility. In addition to acting at the time of the SCIM client call (push, in contrast to the delay of a scheduled AD/AAD pull), it supports entitling users based on SCIM group membership, SCIM User roles, or customer-defined SCIM User attributes. Our SCIM server reflects the entitlement results to the SCIM client in a custom attribute that we added to the SCIM User model. On the backside, our SCIM server provisions and de-provisions users in the managed system and adjusts their entitlements whenever the computed entitlement results change.

The managed system uses a relatively simple, RBAC-like model for authorization. Users have a set of string 'roles', and policies require matching roles. I'm simplifying the policy part for brevity and some IP concerns. My main point is that this system has less 'expressive need' than the resource-oriented platform above. If we were to map this system's policy expressions to the {identity, action, resource} thruple, we'd find that there is a single action (which drops that element) and both identity and resource expressions are sets of strings which only require set arithmetic to handle.

Even though it's common for a system to persist entitlements (as opposed to zero-standing-permission), this system must do so to meet its primary purpose. Think of a high-frequency trading system and try to auth per trade.

[Russell-Allen]

One last entitlement use-case from me. This is the most complicated (to me), making it difficult to convey clearly. I'm hoping you may recognize it as something familiar despite my inexperience-induced hazy description.

Imagine an Application running on a server with its own notion of users and permissions. An enterprise wants to authorize access to that application for select employees. It's simple so far.

Now add a requirement that access to the application is only available over a connection that has its own notion of users and authorization, a VPN being a crude but suitable example.

To eliminate the idea of a single-intermediary solution, let's presume there is potential for additional layers, each with its notion of users and permissions. For example, the application is accessed through a generic terminal application like an ssh session in an embedded web-app.

If I narrow my view to a single boundary between layers, the problem collapses to boilerplate auth federation. But I'm struggling to see if those boilerplate solutions compose up without introducing new problems. This is particularly true when I consider the interplay between approaches like pre-provisioned entitlement vs. no-standing-privilege. Not to mention, should these auth layers collapse to one 'realm' or should they bridge from one to another? - 😕

---

This type of case is at the leading edge of my experience. So, I'm not able to offer much insight into it other than mentioning its existence.

I hope the "Interoperability" in IPSIE is broader than the two-party, enterprise <-> application nature that our conversations tend to presume.

Acknowledging the true breadth of actors and roles seems necessary, both at the IPSIE conformance level and within the specific protocols that might be used to solve this chained, tunneled, web-of-trust thing I've described.

[simon-canning-octopus]

I can speak from 2 SaaS vendor perspectives I've been involved in over the last few years. They contrast slightly. I hope this information is useful.

1. Grammarly

Grammarly is an AI writing assistant. It caters to consumer users via Grammarly, students via Grammarly for Students and teams via Grammarly Business product. For business users it supports SAML and SCIM and both roles and groups can be sync'd from an IdP. There are separate attributes for each. They are single-valued attributes. A user can belongs to one group and have one role assigned.

Roles are used as an access control construct to determines what level of permissions a user has to manage different aspects of a Grammarly Business subscription. There are roles such as admin, account manager, group manager and user. Depending on what role you have determines whether you have read or write permissions to different settings and configurations.

Groups are used to represent logical groupings of users who expect a similar product experience and writing suggestions. For example, the style guides feature allows a customer to specify terms that should be used in writing suggestions and is assigned to a group of users. If you are in the marketing department, your marketing group manager can set marketing specific terms and if you are in sales your sales group manager can specify a different set of terms.

The only relationship between roles and groups is that the group manager role gives the user a set of permissions within the context of the group they are in.

2. Octopus Deploy

Octopus Deploy is a CD tool (as in CI/CD) that helps developers deploy their code to production. It has a self-host and a cloud offering. Octopus Cloud supports IdP integration, predominantly via OIDC. It supports group mappings via Groups or AppRoles at the IdP. I believe these are carried in id tokens at authentication time but I'd need to check. There is no SCIM support but there is group sync support for self-host/on-premise AD.

The Octopus model is more like a traditional RBAC model, but it can get very granular. A user can be assigned to a group ('Team' in Octopus terminology). A Team has a set of roles assigned to it. A role contains the set of permissions that are available. Roles can be scoped more granularly, via 'Spaces' (think Eng Director org level separation), 'Project' (micro-service-a, micro-service-b) and 'Environment' (dev/qa/prod). This scoping is domain centric and currently can't be synced from an IdP. Given the level of granularity, the intent is for most fine-grained permission management to happen within Octopus itself and for coarse-grained provisioning/access control to come from the IdP.

In order to support managing this level of granularity via an Identity Provider, the domain centric view would need to be modelled in the IdP. That feels tedious for someone to do manually because they'd have to really understand the domain.