User/Group lifecycle management #41
Conversation
first draft, needs more work
Following discussion on January 21, 2025 call, I reworked the lifecycle management table.
|
This is a great improvement! The only thing I'm not sure about is the entitlements part, since it sounded like the discussion was leaning towards either leaving entitlements/authorization entirely out of scope or considering it separately. |
|
Happy to remove the entitlements bit if necessary. Personally, I see entitlements as part of provisioning/deprovisioning, but I'm not going to get hung up on that detail. |
Moved entitlements to a separate set of IPSIE Levels E#. I'll remove IPSIE P3 later.
Further clean up. E1 seems unnecessary, consider removing it.
There was a problem hiding this comment.
Largely, this looks good! Two thoughts:
- Imagine an application supports JIT, and when it receives a JIT request it default makes everyone a system admin. This app would be IPSIE P1 compliant. To raise the security bar, we should include language that says if the app receives a JIT request that does not specify permission level, the minimum permissions possible in the app should be applied.
- I think we should do 2 levels for Entitlements (lets delete the current E1 and keep E2 and E3 only). An app that gives no ability for the IdP to manage entitlements (E1) should not be IPSIE compliant.
There was a problem hiding this comment.
Thanks @2MarkMaguire. I agree with your point on entitlements, I'll move E2 / E3 down a level and eliminate what is currently listed as E1.
What do you suggest for the JIT provisioning? As we start writing the profile does it make sense to include a requirement that the JIT provisioning includes some kind of entitlements data (groups, roles, attributes to drive ABAC, etc.)? Or do we include some non-normative text on the risks of excessive entitlements with JIT?
There was a problem hiding this comment.
Regarding JIT, maybe we include some language that says "If an access level is not specified when the account is created by the JIT process, the application must create the account with the least privileges possible in the application"? Something to that effect that says minimum access/least privileges unless the IdP explicitly said in its request give more access than that.
There was a problem hiding this comment.
I like the idea in theory, but this feels like it's really towing the line between interop and policy. I don't think we should have any "MUST" language that describes policy of what a party does, but we could recommend it with a SHOULD since this point in particular is a good one.
There was a problem hiding this comment.
Good point, "should" works for me!
Following an offline discussion with @aaronpk, I have added an intro to provide clarity that the levels are expected to be adhered to by RPs/apps. It is likely this language needs further adjustment, readers should consider this as a starting place for further discussion.
Quick search and replace change of these terms.
changed the terminology following the discussion on the January 28, 2025 WG call.
|
I removed the framing in the introduction and updated the terminology across both the levels and terminology doc. @aaronpk please review and merge this change. Dick can make the changes he suggested to the table. |
I reworked the table to focus on the controls that IPSIE seeks to establish at P1/P2/P3. Each of the cells in the table establishes one or more controls to be met.
This is a strawman to help us continue the discussion from today's call.