2025‐02‐18 - openid/ipsie GitHub Wiki

Date: 2025-02-18

Attendees

  • Kenn Chong (RSA)
  • Aaron Parecki (Okta)
  • Mark Maguire (Aujas Cybersecurity)
  • Filip Skokan (Okta)
  • Tom Clancy (MITRE)
  • Dick Hardt (Hellō)
  • Tim Cappalli (Okta)
  • Karl McGuinness (Self)
  • Russell Allen (Self)
  • Bjorn Hjelm (Yubico)
  • Robin Martherus (Cisco/Duo)
  • Jon Bartlett (Zscaler)
  • Travis Tripp (HPE)
  • Mike Kiser (SailPoint)
  • Pamela Dingle (Microsoft)
  • Brock Allen (Duende)
  • Gennady Shulman (Self)
  • Jen Schreiber (Workday)
  • David Lee ( Self)

Agenda

Notetaker: Mark Maguire

Minutes

  • Antitrust reminder
  • Slack reminder
  • Contribution agreement reminder
  • Aaron: Goal (in agenda) is there anything we can do to make it easier for enterprises to manage entitlements in the app. If there are, is there enough in common to define requirements.
  • Karl: On AuthZen, would be nervous for IPSIE to take an AuthZen dependency in this time. Externalizing auth is a great way to solve it, but not enough real world deployments, so nervous to link the two at this point in time. Only thing proven at scale is management of groups and roles.
  • Mike Kiser: Zero standing privilege is not viable in the near term, seems more like a 5 year ahead thing. Agree with Karl.
  • Karl: Might be a way to lay a path to achieve it today and set groundwork for it to be a PDP. IPSIE should lay out best practices that you can do today.
  • Mike Kiser: Need to say the standardization that allows the management, but don't tie them into authzen or scim
  • Aaron: 2 things were discussed. Authzen versus not and also real time auth decisions or not. It would be nice to have an agreement for the initial scope. Are we discussing provisioning permissions of what users can do or do we want to enable more real time decisions?
  • Mark: Like the idea of provisioning entitlements now, leave the door open for realtime decisions in the future.
  • Aaron: How do we find the commonality between groups and roles to make it a requirement?
  • Mark: The gap seems to be what people call it, whether that's groups or entitlements. As long as we give a clear definition of what we mean, the way it works at a low level is the same.
  • Russell: There seems to be common pattern - in all cases, how policy is expressed is same pattern. Almost language heirarchy: from simplest (a role) to higher level (check the attributes of this thing, if it has the attribute, you mean this policy). Higher level is computing based off attributes. All different approaches to entitlements is doing one of these levels for the identity/role/action. Just need to find generalized terms to describe it.
  • Karl: You might have a group but then individual can have direct assignment inside the app as well. There are direct and indirect relationships there. There is setting permissions, but you need to explode that graph and understand it. If we want to answer the problem statement for the enterprise, "can I prove to an auditor who has what access?" that is a large scale depenedency. We need to define a smaller container - only access can be given from the IdP - if both sides can change access then too hard to handle.
  • Tom: To what extent does the enterprise require the visibility and automation
  • Karl: For IPSIE to have meaning, what problem can it solve that is meaningful? How do we adress long tail, not just the most complex enterprise app. How do I set a baseline of capability. How do I revoke access and ensure it is revoked? If we dont provide a path that is useful to close loop verified access is gone, IPSIE value is decreased.
  • Aaron: Goal of group is not to solve everything everywhere. Want to meaningfully improve baseline in security. Small change in large number of apps is better than full control over small number of apps. Need to capture that.
  • David Lee: Karl mentioned the biggest thing - we often do not know what permissions the entitlements are connected to. The reason sailpoint went with entitlement was to create a more generic term to say "you are assigning something to someone to give access". This construct allows us to decide how to assign access. Provide structures and rules about it. Allows us to move in a better direction and level across.
  • Mark: The initial question was is there enough in common with existing systems to standardize, it seems the answer is yes. Karl mentioned it's great if you remove the entitlement on the IdP but how do you know if the application removed it? We previously said there was a requirement that the application turns off local management.
  • Dick: What David mentioned is right. Something Karl mentioned that "data from enterprise needs to be read only from app." In provisioning, needs to be controlled from identity service. Accounts should only be created from identity service. Likewise, part of agreement with app is that only the identity service can add or remove access. Some attribute about the user should be mapped to within the app. Need an identity attribute that large swath of apps all rely on, so enterprise knows if they change it all apps update. Also, we need to standardize on terms. Need to help enterprises with hundreds of apps to get handle on. Solving broad swath will make a big impact.
  • Aaron: Sounds like we have some consensus. Back to table of levels, how do we describe what we put in the entitlements levels. There has been a discussion about is it achievable / good idea? Sounds like the answer is yes. "Groups" is that a good name? Is it overloaded? Should there be a better title?
  • Dick: I argue for groups. If we are aiming for long tail, microsoft and google use groups. People already familiar with. Readily available for very long tail of organizations. I still think groups are part of identity lifecycle (people added and removed from groups, attribute of identity). For that reason, we dont need entitlement management to be its own levels. We should merge entitlement management levels into identity lifecycle levels.
  • Karl: Flip side of using group as primitive is directly assigning permission to a user. Group is most generic. As group is mapped to application concepts, authorization model brought into play. Leaving it at groups makes no claims abt access statement (group + resource, etc). We know who is in the set, but don't know how else someone might have access. "Group" downside is group does not have an authorization context, it is just collection of users. We need a construct linked to group but not group itself.
  • Dick: So should each app expose its permissions to identity service?
  • Karl: Yes. Expose your roles, map your roles to my groups, and have the mapping at the identity service and not at the application. Role is application specific. Identity service and complexity happens within the identity service.
  • Aaron: So rewrite requirements that instead of provisioning group memberships, instead groups expose roles, identity service consumes roles and assigns to users. Where does that come back to the app? Is it an attribute on the user?
  • Dick: Definitely an attribute of the user. Roles are app specific.
  • Karl: Want the app just to know about its context, and identity service to have a group across those app roles.
  • Russell: Onboarding the app, that set of roles becomes a contract between app vendor and IdP. As an app vendor, we evolve our permission model at a rapid pace. We enable that speed by evolving domain model without breaking the role contract. As long as we can stay underneath, we can move at speed.
  • Mark: If you look at the flow chart on the github issue, I laid out the normal flow for mass, scalable app onboarding. 1) can the app use AD/Okta groups, 2) if not, do they have scim, 3) if not what about webservices? etc. I think we should tell apps they either need to expose their permission model and allow an identity service to manage them or they need to outsource the management to centralized groups like AD.
  • David: Do we want to make it easier for what we do today or do we want to provide a more secure way to do it moving forward? The current workflow is due to limitations (ad groups was easiest, so we do ad groups). We then go down the chart (ad group, scim, api, etc). When you look at it, we know what enterprise does today, lets find a better way to move this forward. How do we make a standard?
  • Karl: Back to framing of long tail and enterpise apps, apps enter in brownfield, cant lose site of shadow it. AD used to be the identity layer. Now with cloud based apps, you have people using apps with distributed auth scenarios, then at some point enterprise takes over management. There are 2 different identity layers needing to be mapped. Would be great if lifecycle started within enterprise but not practical based on how SaaS ISVs grow. They have their own identity service in case client has none of their own. Might not be enterprise managed from day 0. How do we have a more secure "sign in with google" and make it more secure
  • Pam: At some point, what is the success we want to reward? Maybe, right now, success is any automation at all. You tick the box, you get level 1. Is level 0 CSV files? Or is that level 1?
  • Aaron: Back to long tail comment, need some small improvement over current state. Not going for perfect world.
  • Dick: Building on it, I like the model Karl proposed, but maybe further out. Start out with JIT at level 1, level 2 app exposes its roles and what users have which roles. Also, what is anti entropy controls?
  • Aaron: Need to figure out how to update the levels. Apps expose roles to idp and user includes those rules
  • Travis: If we try to push definitions up to high, it will decrease number of people who implement. Role has a lot of dragons, b/c it is a set of permissions on resources. We also have resource based policies, i.e. to access specific resource need to MFA.