Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User/Group lifecycle management #41

Merged
merged 8 commits into from
Jan 29, 2025
Merged

User/Group lifecycle management #41

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
6d7bb3e
Refining levels based on controls
dhs-BI Jan 21, 2025
30dd82e
Lifecycle management updates
dhs-BI Jan 21, 2025
819106e
Separated out entitlements
dhs-BI Jan 22, 2025
0e5f46a
Update ipsie-levels.md
dhs-BI Jan 22, 2025
0df8b82
New introduction
dhs-BI Jan 27, 2025
743c707
Remove intro verbiage.
dhs-BI Jan 29, 2025
38e2a5f
IdP -> Identity Service, RP -> App
dhs-BI Jan 29, 2025
fa43434
Updated terminology - identity service, application
dhs-BI Jan 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 38 additions & 23 deletions ipsie-levels.md
View file
Open in desktop
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, "should" works for me!

Original file line number Diff line number Diff line change
@@ -1,64 +1,79 @@
# IPSIE Levels
# IPSIE


## Session Lifecycle Management

| | Log In | MFA & Log Out | Continuous Access |
|------------------------------|---------------------------------------------------|-----------------------------------------------------------------------|-------------------------------------------------------------------|
| Requirement | IPSIE A1 | IPSIE A2 | IPSIE A3 |
| Single Sign-On | Required (FAL2) | Same as A2 | Same as A2 |
| MFA | IdP-enforced (app doesn't need to do anything). IdP communicates MFA level to app. | IdP MUST accept MFA level requests from the app | Same as A2 |
| Revocation | RP MUST match session lifetime to assertion lifetime | App MUST accept session termination requests from IdP for individual users | Same as A2 |
| Continuous Access (RP->IdP) | None | None | App communicates session changes to IdP such as IP address change |
| Continuous Access (IdP->RP) | None | None | IdP communicates changes in account and device posture to app |
| MFA | Identity Service-enforced (app doesn't need to do anything). Identity Service communicates MFA level to app. | Identity Service MUST accept MFA level requests from the app | Same as A2 |
| Revocation | Application MUST match session lifetime to assertion lifetime | App MUST accept session termination requests from Identity Service for individual users | Same as A2 |
| Continuous Access (Application->Identity Service) | None | None | App communicates session changes to Identity Service such as IP address change |
| Continuous Access (Identity Service->Application) | None | None | Identity Service communicates changes in account and device posture to app |

### IPSIE Authentication Level A1 - Single Sign-On

Level A1 enables basic single sign-on from applications to the identity provider, communicating identity statements about the user. Single sign-on in Level A1 meets the requirements of [FAL2](https://pages.nist.gov/800-63-4/sp800-63c/fal/).

The RP respects the session lifetime as communicated by the IdP in the assertion, and reauthenticates the user through the IdP after the expiration.
The Application respects the session lifetime as communicated by the Identity Service in the assertion, and reauthenticates the user through the Identity Service after the expiration.


### IPSIE Authentication Level A2 - MFA and Log Out

Level A2 adds the ability to communicate information about the user's authentication method between IdP and RP. The IdP includes claims about the authentication level in the assertion to the RP. The RP can request a specific authentication level of the IdP.
Level A2 adds the ability to communicate information about the user's authentication method between Identity Service and Application. The Identity Service includes claims about the authentication level in the assertion to the Application. The Application can request a specific authentication level of the Identity Service.

Level A2 also adds the ability for the IdP to terminate sessions of individual users in the app.
Level A2 also adds the ability for the Identity Service to terminate sessions of individual users in the app.


### IPSIE Authentication Level A3 - Continuous Access

Level A3 adds continuous access to the authentication between IdP and application.
Level A3 adds continuous access to the authentication between Identity Service and application.

The app communicates session changes to the IdP such as IP address change, enabling the IdP to be aware of more context around what is happening to users' sessions after the initial sign-in.
The app communicates session changes to the Identity Service such as IP address change, enabling the Identity Service to be aware of more context around what is happening to users' sessions after the initial sign-in.

The IdP communicates changes in the account and device posture to the application, enabling the application to take actions it determines are necessary based on its own policies about these changes.
The Identity Service communicates changes in the account and device posture to the application, enabling the application to take actions it determines are necessary based on its own policies about these changes.



## Identity Lifecycle Management

| | JIT | Pre-Provisioning | Entitlements |
|------------------------------|---------------------------------------------------|-----------------------------------------------------------------------|-------------------------------------------------------|
| Requirement | IPSIE P1 | IPSIE P2 | IPSIE P3 |
| Provisioning | JIT provisioning from SSO | App MUST allowed 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 |
| | JIT User Provisioning Control | User Pre-Provisioning and Deprovisioning Control|
|------------------------------|---------------------------------------------|-------------------------------------------------|
| Requirement | IPSIE P1 | IPSIE P2 |
| Provisioning Control | User provisioning MUST be controlled by the enterprise via the Identity Service. <br> Out of band provisioning / self provisioning by users SHALL NOT be allowed. | Same as P1 |
| Provisioning | JIT-based provisioning MUST be enabled. | App MUST allow users to be provisioned by the Identity Service prior to sign in. <br> JIT-based provisioning MAY be enabled. |
| Deprovisioning | None | App MUST allow users to be deprovisioned by the Identity Service.|


### IPSIE Provisioning Level P1 - JIT User Provisioning Control

IPSIE Provisioning Level P1 requires the Identity Service to provision users in the application when they log in via SSO. Users must not exist in the application prior to the user logging in for the first time, eliminating alternative pathways for user provisioning (e.g. self-provisioning).

### IPSIE Provisioning Level P2 - User Pre-Provisioning and Deprovisioning Control

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. An application at P2 MUST support pre-provisioning and deprovisioning of users. Identity Services and Apps at P2 MAY support JIT provisioning for downward compatability with an Identity Service / Application operating at Level P1.

## Entitlements Management

### IPSIE Provisioning Level P1 - JIT Provisioning
| | No Entitlements Management Control | Group and Group Membership Pre-Provisioning and Deprovisioning Control| Group and Group Membership Anti-Entropy Control|
|------------------------------|------------------------------------|-----------------------------------------------------------------------|---------------------------------------------------|
| Requirement | IPSIE E1 | IPSIE E2 | IPSIE E3 |
| Entitlements | Entitlements are managed independently by the Identity Service and application | Identity Service and App MUST enable asynchronous pre-provisioning / deprovisioning of groups and group memberships.| Groups and group memberships MUST be controlled by the enterprise via the Identity Service as a single source of truth.<br> <br> Group and group membership provisioning via the App SHALL NOT be allowed. <br> Identity Service and application MUST implement anti-entropy controls for groups and group membership. |

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 Entitlements Management Level E1 - No Entitlements Management Control

IPSIE Level E1 allows the Identity Service and application to independently manage entitlements for users.

### IPSIE Provisioning Level P2 - Pre-Provisioning and Deprovisioning
### IPSIE Entitlements Management Level E2 - Group and Group Membership Pre-Provisioning and Deprovisioning Control

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 E2 adds the capability of communicating groups and group memberships from the Identity Service to the application. Groups and group memberships MUST be pre-provisioned and SHALL NOT be JIT provisioned. Entitlements MAY be managed at the app, however, this is discouraged.

### IPSIE Entitlements Management Level E3 - Group and Group Membership Anti-Entropy Control

### IPSIE Provisioning Level P3 - Entitlements
At Level E3, the Identity Service is a single source of truth regarding the state of the groups and group membership. Building upon E2, the control of provisioning / deprovisionions groups and group membership is the sole responsibility of the Identity Service and SHALL NOT be enabled within the application. Anti-entropy control must be established to prevent drift.

Level P3 adds the capability of communicating groups and group memberships from the IdP to the application.
This SHALL NOT preclude the application from dynamically assessing privileges in real time as a component of session management.



18 changes: 8 additions & 10 deletions ipsie-terminology.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,27 +6,25 @@

Enterprises are generally defined as entities - e.g. corportations, non-profit organizations, partnerships. Enterprises have a workforce comprised of employees, contractors, volunteers, and others who operate on behalf of the enterprise. Enterprises deploy applications and services to support their organizational needs. Government, non-governmental organizations, educational entities, small businesses, and others may consider themselves enterprises.

Ultimately, the goal of the IPSIE standard is to better serve the enterprise organization. Enterprises prefer to centralize the authentication process of all the applications used across the enterprise. Among other benefits, this allows users to have only one set of credentials to manage, and enables the company to manage which users can access which applications in a central location. In this framing, enterprises have user directories, identity providers, relying parties, data, and the policies that are used to grant, suspend, and revoke user access.
Ultimately, the goal of the IPSIE standard is to better serve the enterprise organization. Enterprises prefer to centralize the authentication process of all the applications used across the enterprise. Among other benefits, this allows users to have only one set of credentials to manage, and enables the company to manage which users can access which applications in a central location. In this framing, enterprises have identity services, applications, data, and the policies that are used to grant, suspend, and revoke user access.

The enterprise company is also referred to as the "customer", since they may be a customer of the Identity Provider and multiple Applications.
The enterprise company is also referred to as the "customer", since they may be a customer of the Identity Service provider(s) and multiple Applications.

### Identity Provider
### Identity Service

The enterprise's "Identity Provider", abbreviated IdP, is used by the enterprise to manage users within their organization. The Identity Provider is often purchased by the enterprise company as a service, but can also be open source software or developed in-house.
The enterprise's "Identity Service" the logical set of services used by the enterprise to manage users within their organization. The Identity Service is often purchased by the enterprise company as a service or set of services, but can also be open source software or developed in-house. The identity service may be a single component, or multiple components with discrete functionality.

The identity provider is where the users' access to applications and other resources is managed and enforced.
The identity service is where the users' access to applications and other resources is managed and enforced.

### Application

The "Application" is ultimately used by people within the enterprise company during their day to day work. Applications have their own resources, and users may be limited in which applications they can access or what they can do within an application. Applications use the Identity Provider to authenticate users through a "single sign-on" process.

Applications may also be referred to as the "Relying Party" (RP) during a single sign-on flow.
The "Application" is ultimately used by people within the enterprise company during their day to day work. Applications have their own resources, and users may be limited in which applications they can access or what they can do within an application. Applications use the Identity Service to authenticate users through a "single sign-on" process. Users and entitlements are provisioned to applications through the identity service.

Applications may be purchased by the enterprise company as a service from the application vendor, in which case they are commonly referred to "Software as a Service" (SaaS).

### User

The "User" is part of the workforce of the enterprise company, and is able to use the identity provider to log in to applications.
The "User" is part of the workforce of the enterprise company, and is able to use the Identity Service to log in to applications.

## Terminology

Expand Down Expand Up @@ -74,7 +72,7 @@ A protocol is a set of rules and guidelines for communicating and exchanging dat

### OpenID Connect (OIDC)

A protocol built on top of the OAuth 2.0 framework of specification (IETF RFC 6749 and 6750), used for authentication purposes. OIDC allows for the exchange of identity information between parties, such as an identity provider and a relying party (e.g., a web application). It is designed to provide single sign-on (SSO) capabilities, as well as support for user authentication using JSON Web Tokens (JWTs). OIDC is widely used in modern IAM solutions and is supported by many popular identity providers and service providers.
A protocol built on top of the OAuth 2.0 framework of specification (IETF RFC 6749 and 6750), used for authentication purposes. OIDC allows for the exchange of identity information between parties, such as an Identity Service and a relying party (e.g., a web application). It is designed to provide single sign-on (SSO) capabilities, as well as support for user authentication using JSON Web Tokens (JWTs). OIDC is widely used in modern IAM solutions and is supported by many popular Identity Services and service providers.

### System for Cross-domain Identity Management (SCIM)

Expand Down