-
Notifications
You must be signed in to change notification settings - Fork 9
2025‐02‐25
Aaron Parecki edited this page Mar 3, 2025
·
1 revision
Date: 2025-02-25
- Aaron Parecki (Okta)
- Dean H. Saxe (Beyond Identity)
- Travis Tripp (HPE)
- Hannah Sutor (GitLab)
- Dick Hardt (Hellō)
- Mike Kiser (SailPoint)
- Frederico Valente (Workday)
- Shannon Roddy (self)
- Nagesh Gummadivalli (Workday)
- Russell ALlen (self)
- Gennady Shulman (self)
- Wesley Dunnington (Ping)
- Ameya Hanamsagar (Meta)
- Welcome and antitrust policy reminder
- OpenID Contributor Agreement reminder https://openid.net/intellectual-property
- Reminder about OpenID Slack
- Review Entitlement Management real-world examples
- https://github.com/openid/ipsie/issues/51
- Is there something apps can do to make it easier for the enterprise customer to manage permissions in the app?
- Is there enough in common with real-world examples to standardize this today? Or should we push this out until later?
Notetaker: Dean H. Saxe (Beyond Identity)
- Antitrust policy reminder
- Last week we left off talking about the entitlement management levels
- Dick sent a PR, Aaron has a PR, both based on feedback last week
- Dick - if IL1 is JIT, can IL2 be supportable if we're not supporting JIT
- so this doesn't align well
- Dick suggests JIT is not a part of the lifecycle, therefore, maybe we start with user sync and not JIT
- Aaron - what clicked was the SSO is the session lifecycle track & a requirement. JIT was described as a part of the SSO process. This is not an interop issue. No interop question on JIT provisioning. Remove JIT, no changes to SSO. App behavior if a user is not already created is undefined - so it's no change from current state.
- Travis: Omitting it completely could be odd. JIT is still a part of the lifecycle, sometimes there are timing issues that use JIT. Provisioning in the background can take longer than the timeline for a user to SSO into a system, creating a race condition. JIT is not managing the lifecycle - you created an immortal entity.
- Aaron: makes sense. One option, make JIT creation an option of SSO. This removes it from provisioning.
- Dick: Another way, this is an alt mechanism for provisioning. IL1 could be JIT, but JIT is not required.
- Travis: could create by JIT, but must be managed as part of IL*
- MikeK: IL1 is create?
- Aaron: We don't want a system that is only doing preprovisioning not being compliant with the provisioning track
- Mark: IL is IGA, JIT is provisioning. Need to manage the lifecycle,
- Aaron: Move JIT to SL*, products that don't support provisioning don't have any concerns with this.
- Dick: If we don't add JIT, everyone will ask where it is. Create synchronously or JIT. JIT is not sufficient for IL1
- Aaron: moving JIT to SL* solves this?
- Dick: I don't think of it as part of the session lifecycle
- Aaron: make a requirement of SSO that a user is JIT created if the user doesn't exist.
- Dick: Not the whole lifecycle, only a step in it. Immortal users unless you can manage completely
- Wes: Is the minimum bar immortal creation? Or min bar is lifecycle management.
- Dick: Full lifecycle is minimum
- Travis: JIT with no lifecycle is a security issue. If JIT is in the session, can we create ephemeral session identities
- Wes: That's an issue to discuss, ephemeral identity tied to a session lifetime.
- Dick: Need language on this. Very app specific
- Aaron: backing up. Many concerns:
- Preprovisioning should not be forced to do JIT
- JIT is needed due to race conditions
- Is JIT creation a part of IL or SL?
- MarkM: Correct capture of discussion. Consolidating entitlements created this issue.
- Dean: TODO File an issue on ephemeral identities.
- Dean: If we put JIT in SL can we add explanatory text as to why it fits there even though it's unnatural?
- Dick: SL2 supports JIT? Is that needed?
- Aaron: Yes
- Dick: Do we need a level that doesn't support JIT?
- Mark: there are many apps that support preprovisioning but no JIT.
- Aaron: Maybe the security comment is the way out - requiring JIT doesn't add to security. Maybe we're silent on JIT? JIT is a convenience option. IPSIE can make no guarantees about JIT.
- Gennady: All for JIT. No specs for JIT. If we use this name, it doesn't define anything
- Aaron: Means that user created because of SSO event
- Gennady: Should we call that explanation out?
- Aaron: In a new app, no users, how do users get created? JIT or preprovision.
- Gennady: Or as AWS does, create a role (Dean: is this the ephemeral idea we discussed earlier?)
- Dick: No lifecycle here.
- Gennady: Lifecycle is based on policy, not user.
- Dean: Can we just provide a note on JIT that it's not part of IPSIE, but we recognize that it is useful in some contexts.
- Aaron: Chair hat on, does this work /address concerns?
- Travis: The app MAY allow for users to provision via JIT/SSO, but MUST allow for those users to be managed under IL*.
- Dick: JIT starts at the identity service as a mechanism of provisioning
- Aaron: the issue is that the service provides the SSO assertion to an app with no explicit create user command
- Travis: Main idea - if a user is JIT provisioned, IL* requires that the user be fully managed after JIT provision
- Aaron: Recap
-
- ID service decides if the user can login, would not create assertion if they cannot
-
- Once you bring in lifecycle management, any users created via JIT can be managed via the lifecycle
-
- Dean: agree with this, don't need to define JIT, but need to define that the lifecycle can manage JIT created users
- MikeK: Agree with Dean/Travis/Aaron's recap
- Aaron: the security issue is that JITed users can be managed longterm
- Nagesh: Can we abstract JIT into lifecycle management?
- Aaron: ideal state, but not all apps meet this.
- Dick: clarification - JIT is NOT a requirement for any IL*.
- Aaron: Yes. We are taking a stance, if JIT happens, IL1 allows us to take control over the identity. Dick's PR is in a good state, need to add context on JIT in the description.
- Dick will add the text and we can merge.
- Aaron: this puts us in a good spot on the levels once the PR is merged
- Dean: When do we draw a line to say we've made enough progress so we can start working on normative tet
- Aaron: Goal to get an interop at Gartner in December. We need to choose a level to achieve interop at, this means we need to define the level with text to develop a draft.
- Dean: Homework for next week - what do people think is the right cut line for the interop draft?
- Aaron: Map protocols for levels or cut line at level 1? Thoughts?
- Dick: We'll learn a lot about this when we define a given level. Suggestion: I'll push PR, then we email the list for a discussion.
- Dean / Dick: Let's go define a set of levels and learn what we don't know.
- Dean: Chair hat on - we will start with a mailing list discussion and suggest starting with SL1/IL1
- Mark: can we have parallel tracks to define IL2/SL2
- Dean: Let's not over commit - we focus on Il1/SL1, IL2/SL2 can follow once drafts for the lower levels are defined
- Aaron: scheduling for upcoming meetings will be challenging due to travel, we'll update the WG. We will start with SL1 and then move on to IL1 starting with the next call.
- Dick sent a PR, Aaron has a PR, both based on feedback last week