Skip to content

2025‐02‐11

Jump to bottom
Aaron Parecki edited this page Feb 11, 2025 · 1 revision

Date: 2025-02-11

Attendees

  • Dean H. Saxe (Beyond Identity)
  • Aaron Parecki (Okta)
  • Dick Hardt (Hellō)
  • Sean Miller (RSA)
  • Kenn Chong (RSA)
  • Dave Bryant (RSA)
  • Wesley Dunnington (Ping)
  • Russell Allen
  • Mark Maguire (Aujas Cybersecurity)
  • Robin Martherus
  • Aboobacker MK
  • Brian Soby
  • Russell Allen
  • Jen Schreiber
  • Victor Lu
  • Tom Clancy (MITRE)
  • Ameya Hanamsagar
  • Travis Tripp (HPE)
  • Shannon Roddy (self)
  • Jon Bartlett (Zscaler)
  • Pam Dingle (Microsoft)

Agenda

Notetaker: Dean H. Saxe

Minutes

  • Antitrust reminder

  • Slack reminder

  • Contribution agreement reminder

  • Discussed table of levels at the last meeting, focused on SLn levels

    • made sure the descriptions were formed in terms of requirements of what each role has to do

  • Today, focus on ILn / En levels

    • Aaron rephrased IL/E levels in the same format

  • Dick: question on process / comment on IL levels

    • Are Aaron and Dean both chair and editor?
      • Aaron: in OIDF this is pretty normal for chair/editor roles to be shared.
      • Dean: We welcome more editors if there are any willing partners
    • Dick: Likes the model where the chairs and editors are independent (e.g. IETF)
    • Dick: How do we separate meeting management from Dean/Aaron participation
    • Aaron: It's challenging to get people to contribute at editors. Working on content because it appears that's the expectation of the group.
    • Dick: Wants to see us be productive, hard when editors and chairs are the same people.
    • Sean: Haven't seen a lot of external PRs. No concerns from Sean.
    • Dick: Past meetings have been dominated by the co-chairs/editors. No concerns
    • George: No requirement for chairs and editors to be independent people. WG decides what is best, what works for the WG.
    • Aaron: Right now we're defining the framework, not the profile.

  • Dick: Separating ID Lifecycle from entitlements is not in our best interest - should be a single dimension.

    • Aaron: goal of separate tracks is that products can grow along each independent track.
    • Dick: Groups are inherently attributes of users and vice versa. You can't provision a group without users, so this appears as an extension of groups.
    • Travis: You can have groups without users. Users can be added independently of group creation
    • Dick: groups aren't useful without users. Dick thinks that users/groups are on the same dimension.
    • Russell: Is group an overloaded term? Entitlement track is about authZ, groups tend to be how we discuss authZ.
    • Dean & Aaron: Agree with Russell
    • Aaron (as contributor): are groups the right construct for this level of authZ that we're discussing. Should we instead talk about roles & entitlements as the draft in the SCIM WG discusses. Is this the proper path?
    • Travis: Enterprises care about users/groups in most cases. Associate entitlements to an identity or attribute of an identity, in which sense a group is an attribute. Associate a group to an entitlement then attach user to group which grants entitlements.
    • Dick: agrees. Mapping in the app between user attributes and authZ in the app. AuthZ is contextual to the app. Entitlement is therefore contextual to the app and the user.
    • Aaron: The entitlements are mapped in the identity service. What we need is a way for the app to publish what entitlements it exposes. Published into the identity service where they can be assigned to users/groups. This is very different from what we've written today.
    • Travis: IPSIE level should say we support groups. Support the context/concept of groups
    • Sean: Concept of groups is more abstract - roles/groups/etc. Managing access/entitlements is the thing to expose
    • Dick: We need groups, they are core. Thinks groups are part of the IL mapping. Maybe we need something else mapping attributes to functionality.
    • Aaron: What do you want the app to be able to do based on group sync? How do we define the interop behavior between ID service and App?
    • Dick: ID service isn't creating groups in app. Exposing groups it has at the ID service. App is consuming the groups. ID service decides which to expose to the app. Creating groups at applications implies that they only exist at the app and not the ID Service.
    • Aaron: If apps consume groups from ID service, what do they do with them?
    • Dick: Decides how to map them into the app
    • George: Directionality issue to decide with respect to assignment. Someone has to say, "George can do X within app Y." Could be due to group membership where enterprise admin says "group X gets these privileges at App Y". Alt, Identity service sends its authZ model to the app. Assignment happens at the ID service. We can't leak secret groups to apps. roles/Attributes are incompatible with graph based authZ. Where does assignment of capabilities happen? App? Identity service?
    • MarkM: Nomenclature difference based on where we come from. Entitlement is the superset of group/role/profile. Need to define nomenclature.
    • WesD: We need a lingua franca between the systems. There are multiple possible use cases - how prescriptive do we wish to be? We need to tease out provisioning from entitlement. Thinks groups/entitlements should be in the IL levels.
    • Dick: group is an attribute of the user. Maybe En needs to be authZ lifecycle.
    • WesD: Group is one way to get entitlements.
    • Dick: Works for smaller orgs. Roles are like groups... AWS Roles are very specific account oriented things. (Dean side note: Model is not universal across all systems)
    • Pam: agrees with Dick. Many ways to do this work. Maybe this is going too far? There are many ways to solve the problem and they may be equally secure.
    • Aaron: Makes sense. Focus on secure, interop profiles. As we get into authZ management, there are many ways.
    • SeanM: I was getting at the same idea.
    • Dean: At what point do we decide this is a big challenge that we cannot solve easily? Maybe we punt on this and focus on IL/SL for now.
    • Travis: Agreement.
    • MarkM: Difficult issue. Not sure we achieve our goals if we don't solve how to manage authorization within apps at the Identity services.
    • Russell: Concur with Pam, this is a conformance statement. At a later stage we should define how to achieve a specific conformance level through specific protocols/mechanisms.
    • Pam: This is a directionality conversation (agrees with George). Value in saying, "here's how to sync groups securely". Repeat for roles, etc. If we define entitlements many people may not be able to conform today. Need to understand whether people can adopt this model. Maybe there's a groups level 1 and a roles level 1 to put a stake in the ground for how we get to a level 2 on both. Doesn't penalize someone for opting out of these levels. Can define based on what we believe is current best practice.
    • Aaron: helpful framing
    • WesD: OIDF strength is that every requirement is a testable requirement. Cannot be vague. All levels must have a concrete set of tests.
    • Shannon: SAML - expresses groups, entitlements, etc. as attributes. Finding apps that can consume these and use them is rare in his experience.
    • Aaron: Asks Shannon, can you tell your apps how to uplevel by consuming this information?
    • Shannon: Agree on the goal, sceptical on whether apps will get there. Asking people to be proficient in IAM when they are not.
    • Aaron: We need to make it as easy as possible for the apps/non-IAM oriented admins
    • Shannon: Do we have service providers at the table
    • Russell: Yes, me. Agree with Shannon. One of our big challenges is our authZ model is bespoke to our app. No good mechanism to expose this model to the identity service.
    • Dick: Tell us more.
    • Russell: Our model is atypical. Set of resources that we control authZ to, CRUD permissions per resource. Multi-tenant, so we need to impose tenant level authZ boundaries. Resources are hierarchical, high level roles give access to subsets of the resource tree.
    • Dick: Is all management of authZ done at the app? Do you consume any authZ from the identity service?
    • Russell: Managed internally only. May get federated role, not permissions at an atomic level. Depending on the part of the app, there may be no ability to assign permissions from the identity service.
    • Dick: We need some coarse grained controls - role/group - for authZ.
    • Russell: developing a SCIM server designed to allow selection of attributes to sync (?). Would be helpful to not have to sync all attributes.
    • MarkM: we're all biased by our past experiences. E1/2 feels like 40-50% of systems could meet these levels regardless of protocol. Most modern apps allow provisioning. Set standards that allow an IdP/IGA to provision authorization without defining a mechanism.
    • Aaron: Getting to interop. 2 phases: high level issues first, then specific implementations. If we have many different mechanisms, we have not achieved interop.
    • Travis: happy to share some use cases at a future meeting. Echoes Mark's statement. Needs an interface to provision authZ for users. We can be opinionated on the mechanism. Groups is the most common interface Travis sees in real world deployments.
    • Pam: We're getting to a thru-line. Interop - what are you asking your Identity services to do? Are you asking for attributes? Is there a security pattern for how they are sent to the app? Maybe we work thisby considering what any service provider wants from an identity service to attack known security risks?

  • Aaron: what's the next step?

  • Dean: Collect docs on how authZ is managed in different tools.

  • Aaron: review those next week. Aaron will create an issue for people to add their data to.

Clone this wiki locally