Update ipsie-levels.md #37
Conversation
Updated level definitions for lifecycle management.
| | Provisioning | JIT provisioning from SSO | App MUST allow users to be provisioned by the IdP before they sign in | Same as P2 | | ||
| | Deprovisioning | None | App MUST allow users to be deprovisioned by the IdP | Same as P2 | | ||
| | Entitlements | None | None | Group provisioning and deprovisioning from IdP to app | | ||
| | Meta Data Updates | None | None | Account metadata can be updated from the IdP | |
There was a problem hiding this comment.
I'd like to discuss this further on the next call to understand the motivation behind changes from group provisioning to metadata provisioning. In my mind these are not equivalent concepts and may not capture the intent of provisioning users and groups at the RP.
There was a problem hiding this comment.
On last call there was a discussion about moving from 3 groups to 2. After rewriting the decision for group 2 I thought about omitting group 3, but then decided to include this to see the group's thoughts.
| ### IPSIE Provisioning Level P1 - JIT Provisioning | ||
|
|
||
| IPSIE Provisioning Level P1 enables the IdP to provision users in the application when they log in via SSO. Users are not expected to exist in the application prior to the user logging in for the first time. | ||
| IPSIE Provisioning Level P1 enables the IdP to provision users in the application when they log in via SSO. Users are not expected to exist in the application prior to the user logging in for the first time. The application must also be configurable to allow an enterprise to restrict users from directly creating an account through an alternate sign-up method (such as "Create Account with Email"). When this restriction is applied, the only mechanism for account creation will be through the enterprise's IAM tools. Additionally, the account which is created through the JIT process must not be overpermissioned. If the IdP does not specify the level of access the user should have during account creation, the new account must be created with the minimum level of application access possible. |
There was a problem hiding this comment.
You have a good point on restricting alternative signup methods that has not been adequately captured elsewhere. I'm not sure this belongs in the category of JIT provisioning, however, it should be considered for these levels.
The permissions are fundamentally business rules. IPSIE should avoid attempts to codify business rules. However, this may be a non-normative part of IPSIE best practices.
| ### IPSIE Provisioning Level P2 - Pre-Provisioning and Deprovisioning through Groups | ||
|
|
||
| Level P2 adds the ability to provision and deprovision users in the application before they have logged in. Prior to level P2, users were only JIT-provisioned in the application as part of SSO. | ||
| Level P2 adds the ability to provision and deprovision accounts and an account's access in the application without the user needing to login. Prior to Level P2, users were only JIT-provisioned in the application as part of SSO. Also, the application must support a protocol or provide an interface that allows the IdP to read and edit the access levels of the application's accounts. |
There was a problem hiding this comment.
Wouldn't the last sentence be captured by the earlier language on group provisioning/deprovisioning? As written, at P2 IPSIE profiles could support non-standard provisioning interfaces which are contrary to the goals of the profile.
There was a problem hiding this comment.
Yes, and just to clarify, these levels should be written without mentioning protocols, but the intent is very much that later we'll make an explicit choice of which protocols to use to accomplish the features at each level.
| Level P2 adds the ability to provision and deprovision users in the application before they have logged in. Prior to level P2, users were only JIT-provisioned in the application as part of SSO. | ||
| Level P2 adds the ability to provision and deprovision accounts and an account's access in the application without the user needing to login. Prior to Level P2, users were only JIT-provisioned in the application as part of SSO. Also, the application must support a protocol or provide an interface that allows the IdP to read and edit the access levels of the application's accounts. | ||
|
|
||
| Additionally, for Level P2, the application must support the ability for all access levels within the application to be "mapped" to access groups within the IdP. The application must also provide a configuration to allow an enterprise to prevent IdP-managed accounts from being given access directly within the application. This will provide the enterprise with an assurance that the identity's group membership within the IdP accurately reflects the level of access the identity's account has within the application. |
There was a problem hiding this comment.
I'm not clear how this requirement provides assurance that the IdP and RP are in sync on the group membership. This will most certainly be protocol specific, e.g. the ongoing discussions in SCIM WG on delta queries and cursor based pagination to address known gaps in the ability to implement anti entropy controls with SCIM. (I'm not suggesting SCIM must be used, this is an example only).
dhs-BI
left a comment
dhs-BI
left a comment
There was a problem hiding this comment.
Let's discuss this on the next call. There are some interesting threads to pull on here .
I have concerns about moving P3 from group provisioning to metadata provisioning and wish to understand this better.
|
With #41 being merged this morning, and the discussion on the call on January 28, how would we like to handle this PR? @2MarkMaguire is there something remaining in this PR that we should pull forward into the ipsie-levels? |
|
Given the recent updates, is there anything in this PR that needs to be pulled forward into the latest version? If not, I suggest we close the PR without merging. @aaronpk and @2MarkMaguire, what do you think? |
|
Levels updated by Dean's PR, closing this one. |
3 participants
Updated level definitions for lifecycle management.