From e1d38b4219c8c9b35af188a181cde1a5894e109c Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Fri, 2 May 2025 16:07:37 -0400 Subject: [PATCH 01/16] Create IL1-SCIM.md --- IL1-SCIM.md | 149 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 IL1-SCIM.md diff --git a/IL1-SCIM.md b/IL1-SCIM.md new file mode 100644 index 0000000..0aeb064 --- /dev/null +++ b/IL1-SCIM.md @@ -0,0 +1,149 @@ +# Abstract +The IPSIE IL1 SCIM 2.0 Profile defines a profile of SCIM 2.0 intended to meet the security and interoperability requirements of enterprise integrations using SCIM. It establishes a clear baseline for provisioning and lifecycle management of enterprise users and the roles those users are assigned. The IL1 specification ensures that CRUD operations initiate from the Identity Service and that local modifications within the Application do not occur. + + +# 1.0 Introduction +This document defines the IPSIE Identity Lifecycle 1 (SL1) Profile for SCIM 2.0. It provides a clear reference for SCIM deployments that require a well-defined security baseline meeting best practices for interoperable enterprise identity management. + +The profile addresses critical aspects of secure identity management, with particular emphasis on: +* Client Authentication +* Creation, Update, and Deletion of accounts +* Synchronization of data from the Identity Service to the Application + +By adhering to this profile, organizations can implement SCIM-based integrations that meet stringent security requirements while ensuring interoperability across different implementations. + +# 2.0 Conventions and Definitions +The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings. + + +## 2.1 Terminology +The terms "SCIM", "SCIM Client", and "SCIM Service" refer to the terminology defined in [RFC 7644]. + +## 2.2 Roles +* **Identity Service**: Acts as the SCIM Client, initiating all provisioning operations. +* **Application**: Acts as the SCIM Service, hosting SCIM endpoints and processing all provisioning requests. + + +# 3.0 Profile + +## 3.1 Client Authentication +Identity Services shall authenticate to the Application's SCIM endpoint using OAuth 2.0 with the JWT Authorization Grant (RFC 7523). All of the following conditions should be met: +* The token shall exchange a signed JWT for an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests. +* The token must be scoped to "scim" and not grant broader permissions. +* The token must contain a "token_endpoint" value which is the URL of the Application Provider's OAuth 2.0 token endpoint. + +Additionally, the Identity Service should expose a jwks_uri to allow the Application to perform signature verification + +## 3.2 SCIM Interoperability Requirements + +### 3.2.1 General Requirements +* The Identity Service shall implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. +* The Application shall implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. +* All SCIM operations shall be authenticated via OAuth 2.0; local modifications are prohibited. + +### 3.2.2 User Provisioning Operations +The Application MUST provide support all User provisioning operations defined in this section. + +#### 3.2.3 Create User (POST /Users) +User creation is performed by the SCIM operation POST /Users + +#### 3.2.4 Update User (PATCH /Users/{id}) +User updates are performed via the SCIM operation: PATCH /Users/{id} + +#### 3.2.5 Deactivate or Reactivate User (PATCH /Users/{id}) +Changes to the user activation status are performed via the SCIM operation: PATCH /Users/{id} + +The Identity Service SHOULD propagate user deactivation events to the Application within 5 minutes of the user being deactivated. + +The Application SHOULD respond to user deactivation events by revoking the ability for the user to continue accessing the Application, including the revocation of currently active sessions. The revocation mechanism is an implementation detail outside the scope of this specification. Revocation SHOULD occur within 5 minutes of receiving the deactivation. + +The Application MUST allow reactivation of a deactivated user. + +#### 3.2.6 Delete User (DELETE /Users/{id}) +User deletions are performed via the SCIM operation: DELETE /Users/{id} + +After a user is deleted, Application MUST allow the creation of a new user with the same username. + +#### 3.2.7 Get User By ID (GET /Users/{id}) +User searches by id are performed via the SCIM operation: GET /Users/{id} + +#### 3.2.8 List Users By Alternate Identifier (GET /Users?) +User searches by alternate identifier are performed via the SCIM operation: GET /Users?filter={filterExpression} + +Application Providers MUST support the following filter expressions: +* username eq {username} +* externalId eq {externalId} +* emails[value eq {email}] + +### 3.3 Group (Role) Provisioning Operations +The Application MUST provide support all Group provisioning operations defined in this section. + +**Note**: Within the IPSIE standard, Application permissions are referred to as "Roles." Within SCIM, Application permissions are referred to as "Groups." The term "Role" in IPSIE is functionally equivalent to the term "Group" in SCIM. + +#### 3.3.1 Get Group By ID (GET /Group/{id}) +Group searches by id are performed via the SCIM operation: GET /Group/{id}?excludedAttributes=members + +#### 3.3.2 List Groups By Alternate Identifier (GET /Groups?) +User lookups by alternate identifier are performed via the SCIM operation: GET /Groups?filter={filterExpression}&excludedAttributes=members + +#### 3.3.3 Add or Remove Group Members (PATCH /Group/{id}) +Members are added or removed from Groups via the SCIM operation: PATCH /Groups/{id} + +For each Operation in the PATCH: + +The op attribute MUST contain either "add" or "remove". +* When the op is "add": + * The path attribute MUST be "members". + * The value attribute MUST be an array of Group member elements, as defined in Section 4.2 of the SCIM Core Schema [RFC7643]. Each member MUST contain a value subattribute with the id of the resource being added to the group. + +* When the op is "remove": + * The path attribute MUST be either: + * "members" (to remove all members) + * "members[value eq \"{id}\"]" (to remove a single member) + * The value attribute MUST be unspecified. + +### 3.4 Metadata Endpoints + +#### 3.4.1 /ResourceTypes +Application MUST host a /ResourceTypes endpoint, as defined in Section 4 of RFC 7644. + +The supported ResourceTypes MUST include Users and Groups. + +#### 3.4.2 /ServiceProviderConfig +Application Providers MUST host a /ServiceProviderConfig endpoint to describe the operations they support, as defined in Section 4 of RFC 7644. + +The operations MUST include, at minimum, the set of SCIM capabilities required for compatibility with this IPSIE profile. + +#### 3.4.3 /Schemas +Application Providers MUST host a /Schemas endpoint to describe the supported schemas, as defined in Section 4 of RFC 7644. + +# 4.0 Security Considerations +For SCIM security considerations, see RFC 7643 and RFC 7644. + +Additionally, the following security considerations must be included: +* **Transport Security**: All endpoints shall enforce TLS 1.2 or later with strong cipher suites and certificate validation. +* **Error Handling**: Error responses shall use the SCIM error format and shall not leak internal details. +* **Replay Resistance**: Access tokens shall expire and nonces shall be validated to prevent replay. +* **Auditing**: All provisioning actions and responses shall be logged for audit and troubleshooting. + +# 5.0 Compliance Statement +Implementation of all mandatory requirements in this profile will result in a SCIM 2.0 deployment that satisfies IPSIE Identity Lifecycle Level 1 (IL1). Specifically: + +* **Identity Service (SCIM Client)** + * Shall initiate all CRUD operations for Users and Groups. + +* **Application (SCIM Service)** + * Shall host all SCIM endpoints with full support for User and Group provisioning. + * Shall prevent local modifications outside of SCIM. + * Shall enforce OAuth 2.0 JWT Profile for authentication and adhere to the security considerations above. + +By conforming to this profile, implementations will achieve a consistent, secure, and interoperable baseline for enterprise identity lifecycle management. + +## 6.0 Normative References +TODO + +## 7.0 Acknowledgements +TODO + +## 8.0 Author's Address +TODO From f0b1a0bdbd8029a713bd299151711e03eb967263 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Wed, 4 Jun 2025 18:30:54 -0400 Subject: [PATCH 02/16] Update IL1-SCIM.md Fix per Karl's comment. Auth will use JWT Client Authentication, not JWT Authorization Grant. --- IL1-SCIM.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 0aeb064..37890da 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -27,7 +27,7 @@ The terms "SCIM", "SCIM Client", and "SCIM Service" refer to the terminology def # 3.0 Profile ## 3.1 Client Authentication -Identity Services shall authenticate to the Application's SCIM endpoint using OAuth 2.0 with the JWT Authorization Grant (RFC 7523). All of the following conditions should be met: +Identity Services shall authenticate to the Application's SCIM endpoint using OAuth 2.0 with the JWT Client Authentication (RFC 7523). All of the following conditions should be met: * The token shall exchange a signed JWT for an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests. * The token must be scoped to "scim" and not grant broader permissions. * The token must contain a "token_endpoint" value which is the URL of the Application Provider's OAuth 2.0 token endpoint. From c6b8b5109c85fa4a0fce57c29b37aca18e44f6e5 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 10:57:39 -0400 Subject: [PATCH 03/16] Update IL1-SCIM.md Updated to address Karl's comment on "All of the Authorization Server parameters should be discovered from OAuth Authorization Server metadata" --- IL1-SCIM.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 37890da..3dfebf8 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -31,8 +31,8 @@ Identity Services shall authenticate to the Application's SCIM endpoint using OA * The token shall exchange a signed JWT for an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests. * The token must be scoped to "scim" and not grant broader permissions. * The token must contain a "token_endpoint" value which is the URL of the Application Provider's OAuth 2.0 token endpoint. - -Additionally, the Identity Service should expose a jwks_uri to allow the Application to perform signature verification +* All Authorization Server parameters should be discovered from OAuth Authorization Server metadata. +* The Identity Service should expose a jwks_uri to allow the Application to perform signature verification ## 3.2 SCIM Interoperability Requirements From f790d08effcc97ae17110d856db7f245e3542bad Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 11:25:34 -0400 Subject: [PATCH 04/16] Update IL1-SCIM.md Updated to make OAuth 2.0 Requirements section and to include reference to RFC 8414 --- IL1-SCIM.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 3dfebf8..257a511 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -26,12 +26,13 @@ The terms "SCIM", "SCIM Client", and "SCIM Service" refer to the terminology def # 3.0 Profile -## 3.1 Client Authentication -Identity Services shall authenticate to the Application's SCIM endpoint using OAuth 2.0 with the JWT Client Authentication (RFC 7523). All of the following conditions should be met: +## 3.1 OAuth 2.0 Requirements +Identity Services shall integrate with the Application's SCIM endpoint using OAuth 2.0 for secure authorization and token-based authentication. The following requirements ensure consistent and secure handling of access tokens and authorization server configuration: +* OAuth 2.0 interactions must comply with JWT Client Authentication as defined in RFC 7523. * The token shall exchange a signed JWT for an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests. * The token must be scoped to "scim" and not grant broader permissions. * The token must contain a "token_endpoint" value which is the URL of the Application Provider's OAuth 2.0 token endpoint. -* All Authorization Server parameters should be discovered from OAuth Authorization Server metadata. +* All Authorization Server parameters should be discovered from OAuth Authorization Server metadata as defined in RFC 8414. * The Identity Service should expose a jwks_uri to allow the Application to perform signature verification ## 3.2 SCIM Interoperability Requirements From 6b5097e75ad3e4fec1f00fcd325e774a9bbffc58 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 11:36:51 -0400 Subject: [PATCH 05/16] Update IL1-SCIM.md Updated to include a list of what needs to be revoked when an account is suspended to address comment "Suspending an account needs to have stronger guarantee on what is revoked" --- IL1-SCIM.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 257a511..2a8b1fd 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -58,6 +58,14 @@ The Identity Service SHOULD propagate user deactivation events to the Applicatio The Application SHOULD respond to user deactivation events by revoking the ability for the user to continue accessing the Application, including the revocation of currently active sessions. The revocation mechanism is an implementation detail outside the scope of this specification. Revocation SHOULD occur within 5 minutes of receiving the deactivation. +When a user account is deactivated, all access mechanisms and authorizations associated with that account must also be deactivated. This includes, but is not limited to: +* Web sessions +* API tokens +* Refresh tokens +* Personal access tokens +* SSH keys associated with the user +* Device-based authentication credentials + The Application MUST allow reactivation of a deactivated user. #### 3.2.6 Delete User (DELETE /Users/{id}) From e0fa084cb07172446734efab97b0c0705f10cd56 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 11:51:11 -0400 Subject: [PATCH 06/16] Update IL1-SCIM.md Updated to address Karl's comment "We need a minimum profile to enable the use cases at SL1 (e.g externalId and active. We can also provide standard mappings but not require the attributes to be require" --- IL1-SCIM.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 2a8b1fd..3f53369 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -48,6 +48,10 @@ The Application MUST provide support all User provisioning operations defined in #### 3.2.3 Create User (POST /Users) User creation is performed by the SCIM operation POST /Users +In addition to the user attributes required by RFC 7643, the following attributes are required to be part of the account schema: +* An attribute which contains a unique identifier used by the enterprise to distinguish the owner of the account, such as "externalId." +* An attribute which contains the primary email address of the user, such as "email" + #### 3.2.4 Update User (PATCH /Users/{id}) User updates are performed via the SCIM operation: PATCH /Users/{id} From 54489f36af5f5aa102b6752abf7364952f1df02b Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 11:56:33 -0400 Subject: [PATCH 07/16] Update IL1-SCIM.md Updated to address Karl's comment, "Any requirements needed for users that were created via SSO JIT but now need to be managed identities via SCIM?" --- IL1-SCIM.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 3f53369..74190b7 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -77,10 +77,15 @@ User deletions are performed via the SCIM operation: DELETE /Users/{id} After a user is deleted, Application MUST allow the creation of a new user with the same username. -#### 3.2.7 Get User By ID (GET /Users/{id}) +#### 3.2.7 Get All Users (GET /Users) +A search for all users in the system are performed by the SCIM operation: GET /Users/ + +This endpoint ensures that any accounts which were made by a Just-in-Time (JIT) provisioning action can be managed by the Identity Service. + +#### 3.2.8 Get User By ID (GET /Users/{id}) User searches by id are performed via the SCIM operation: GET /Users/{id} -#### 3.2.8 List Users By Alternate Identifier (GET /Users?) +#### 3.2.9 List Users By Alternate Identifier (GET /Users?) User searches by alternate identifier are performed via the SCIM operation: GET /Users?filter={filterExpression} Application Providers MUST support the following filter expressions: From 2f9304b64c32260f32eb1f01ee4f6448866a0c54 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 13:28:51 -0400 Subject: [PATCH 08/16] Update IL1-SCIM.md Updated Get All Users to include: To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Relying Party shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. --- IL1-SCIM.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 74190b7..4fbcb52 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -78,10 +78,12 @@ User deletions are performed via the SCIM operation: DELETE /Users/{id} After a user is deleted, Application MUST allow the creation of a new user with the same username. #### 3.2.7 Get All Users (GET /Users) -A search for all users in the system are performed by the SCIM operation: GET /Users/ +A search for all users in the system are performed by the SCIM operation: GET /Users This endpoint ensures that any accounts which were made by a Just-in-Time (JIT) provisioning action can be managed by the Identity Service. +To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Relying Party shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. + #### 3.2.8 Get User By ID (GET /Users/{id}) User searches by id are performed via the SCIM operation: GET /Users/{id} @@ -98,13 +100,20 @@ The Application MUST provide support all Group provisioning operations defined i **Note**: Within the IPSIE standard, Application permissions are referred to as "Roles." Within SCIM, Application permissions are referred to as "Groups." The term "Role" in IPSIE is functionally equivalent to the term "Group" in SCIM. -#### 3.3.1 Get Group By ID (GET /Group/{id}) +#### 3.3.1 Get All Groups (GET /Groups) +A search for all groups in the system are performed by the SCIM operation: GET /Groups + +This endpoint ensures that any all groups can be managed by the Identity Service. + +To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Relying Party shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. + +#### 3.3.2 Get Group By ID (GET /Group/{id}) Group searches by id are performed via the SCIM operation: GET /Group/{id}?excludedAttributes=members -#### 3.3.2 List Groups By Alternate Identifier (GET /Groups?) +#### 3.3.3 List Groups By Alternate Identifier (GET /Groups?) User lookups by alternate identifier are performed via the SCIM operation: GET /Groups?filter={filterExpression}&excludedAttributes=members -#### 3.3.3 Add or Remove Group Members (PATCH /Group/{id}) +#### 3.3.4 Add or Remove Group Members (PATCH /Group/{id}) Members are added or removed from Groups via the SCIM operation: PATCH /Groups/{id} For each Operation in the PATCH: From 9d09103a981d3f594fed3b4b8a405695893290f6 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 13:36:08 -0400 Subject: [PATCH 09/16] Update IL1-SCIM.md Updated to include rate limiting requirements --- IL1-SCIM.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 4fbcb52..68faebb 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -82,7 +82,7 @@ A search for all users in the system are performed by the SCIM operation: GET /U This endpoint ensures that any accounts which were made by a Just-in-Time (JIT) provisioning action can be managed by the Identity Service. -To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Relying Party shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. +To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Application shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. #### 3.2.8 Get User By ID (GET /Users/{id}) User searches by id are performed via the SCIM operation: GET /Users/{id} @@ -105,7 +105,7 @@ A search for all groups in the system are performed by the SCIM operation: GET / This endpoint ensures that any all groups can be managed by the Identity Service. -To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Relying Party shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. +To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Application shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. #### 3.3.2 Get Group By ID (GET /Group/{id}) Group searches by id are performed via the SCIM operation: GET /Group/{id}?excludedAttributes=members @@ -152,6 +152,7 @@ Additionally, the following security considerations must be included: * **Error Handling**: Error responses shall use the SCIM error format and shall not leak internal details. * **Replay Resistance**: Access tokens shall expire and nonces shall be validated to prevent replay. * **Auditing**: All provisioning actions and responses shall be logged for audit and troubleshooting. +* **Rate Limiting**: All endpoints shall enforce rate limiting and must respond with "429 Too Many Requests" when limits are exceeded. # 5.0 Compliance Statement Implementation of all mandatory requirements in this profile will result in a SCIM 2.0 deployment that satisfies IPSIE Identity Lifecycle Level 1 (IL1). Specifically: From d89810701312af403566b6c9ff32435efefff5e2 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 13:43:22 -0400 Subject: [PATCH 10/16] Update IL1-SCIM.md Updating to say both the User and Group schema definitions are required --- IL1-SCIM.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 68faebb..554c116 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -142,7 +142,7 @@ Application Providers MUST host a /ServiceProviderConfig endpoint to describe th The operations MUST include, at minimum, the set of SCIM capabilities required for compatibility with this IPSIE profile. #### 3.4.3 /Schemas -Application Providers MUST host a /Schemas endpoint to describe the supported schemas, as defined in Section 4 of RFC 7644. +Application Providers MUST host a /Schemas endpoint to describe the supported schemas, as defined in Section 4 of RFC 7644. There must be a schema for both Users and Groups. The schemas must include all required attributes from RFC 7643 and from Section 3.2.3 (Create User). # 4.0 Security Considerations For SCIM security considerations, see RFC 7643 and RFC 7644. From 758aa08ea1d6ef333a1e3059a4dc81630ecaff60 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 13:50:19 -0400 Subject: [PATCH 11/16] Update IL1-SCIM.md Updating capitalization --- IL1-SCIM.md | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 554c116..d75483e 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -13,7 +13,7 @@ The profile addresses critical aspects of secure identity management, with parti By adhering to this profile, organizations can implement SCIM-based integrations that meet stringent security requirements while ensuring interoperability across different implementations. # 2.0 Conventions and Definitions -The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings. +The keywords "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "CAN" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings. ## 2.1 Terminology @@ -27,20 +27,20 @@ The terms "SCIM", "SCIM Client", and "SCIM Service" refer to the terminology def # 3.0 Profile ## 3.1 OAuth 2.0 Requirements -Identity Services shall integrate with the Application's SCIM endpoint using OAuth 2.0 for secure authorization and token-based authentication. The following requirements ensure consistent and secure handling of access tokens and authorization server configuration: +Identity Services SHALL integrate with the Application's SCIM endpoint using OAuth 2.0 for secure authorization and token-based authentication. The following requirements ensure consistent and secure handling of access tokens and authorization server configuration: * OAuth 2.0 interactions must comply with JWT Client Authentication as defined in RFC 7523. -* The token shall exchange a signed JWT for an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests. +* The token SHALL exchange a signed JWT for an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests. * The token must be scoped to "scim" and not grant broader permissions. * The token must contain a "token_endpoint" value which is the URL of the Application Provider's OAuth 2.0 token endpoint. -* All Authorization Server parameters should be discovered from OAuth Authorization Server metadata as defined in RFC 8414. -* The Identity Service should expose a jwks_uri to allow the Application to perform signature verification +* All Authorization Server parameters SHOULD be discovered from OAuth Authorization Server metadata as defined in RFC 8414. +* The Identity Service SHOULD expose a jwks_uri to allow the Application to perform signature verification ## 3.2 SCIM Interoperability Requirements ### 3.2.1 General Requirements -* The Identity Service shall implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. -* The Application shall implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. -* All SCIM operations shall be authenticated via OAuth 2.0; local modifications are prohibited. +* The Identity Service SHALL implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. +* The Application SHALL implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. +* All SCIM operations SHALL be authenticated via OAuth 2.0; local modifications are prohibited. ### 3.2.2 User Provisioning Operations The Application MUST provide support all User provisioning operations defined in this section. @@ -82,7 +82,7 @@ A search for all users in the system are performed by the SCIM operation: GET /U This endpoint ensures that any accounts which were made by a Just-in-Time (JIT) provisioning action can be managed by the Identity Service. -To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Application shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. +To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Application SHALL enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. #### 3.2.8 Get User By ID (GET /Users/{id}) User searches by id are performed via the SCIM operation: GET /Users/{id} @@ -105,7 +105,7 @@ A search for all groups in the system are performed by the SCIM operation: GET / This endpoint ensures that any all groups can be managed by the Identity Service. -To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Application shall enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. +To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Application SHALL enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. #### 3.3.2 Get Group By ID (GET /Group/{id}) Group searches by id are performed via the SCIM operation: GET /Group/{id}?excludedAttributes=members @@ -148,22 +148,22 @@ Application Providers MUST host a /Schemas endpoint to describe the supported sc For SCIM security considerations, see RFC 7643 and RFC 7644. Additionally, the following security considerations must be included: -* **Transport Security**: All endpoints shall enforce TLS 1.2 or later with strong cipher suites and certificate validation. -* **Error Handling**: Error responses shall use the SCIM error format and shall not leak internal details. -* **Replay Resistance**: Access tokens shall expire and nonces shall be validated to prevent replay. -* **Auditing**: All provisioning actions and responses shall be logged for audit and troubleshooting. -* **Rate Limiting**: All endpoints shall enforce rate limiting and must respond with "429 Too Many Requests" when limits are exceeded. +* **Transport Security**: All endpoints SHALL enforce TLS 1.2 or later with strong cipher suites and certificate validation. +* **Error Handling**: Error responses SHALL use the SCIM error format and SHALL NOT leak internal details. +* **Replay Resistance**: Access tokens SHALL expire and nonces SHALL be validated to prevent replay. +* **Auditing**: All provisioning actions and responses SHALL be logged for audit and troubleshooting. +* **Rate Limiting**: All endpoints SHALL enforce rate limiting and must respond with "429 Too Many Requests" when limits are exceeded. # 5.0 Compliance Statement Implementation of all mandatory requirements in this profile will result in a SCIM 2.0 deployment that satisfies IPSIE Identity Lifecycle Level 1 (IL1). Specifically: * **Identity Service (SCIM Client)** - * Shall initiate all CRUD operations for Users and Groups. + * SHALL initiate all CRUD operations for Users and Groups. * **Application (SCIM Service)** - * Shall host all SCIM endpoints with full support for User and Group provisioning. - * Shall prevent local modifications outside of SCIM. - * Shall enforce OAuth 2.0 JWT Profile for authentication and adhere to the security considerations above. + * SHALL host all SCIM endpoints with full support for User and Group provisioning. + * SHALL prevent local modifications outside of SCIM. + * SHALL enforce OAuth 2.0 JWT Profile for authentication and adhere to the security considerations above. By conforming to this profile, implementations will achieve a consistent, secure, and interoperable baseline for enterprise identity lifecycle management. From 17383217f6b37defc28137c1d8061a093d16e974 Mon Sep 17 00:00:00 2001 From: 2MarkMaguire <33714158+2MarkMaguire@users.noreply.github.com> Date: Tue, 15 Jul 2025 13:51:29 -0400 Subject: [PATCH 12/16] Update IL1-SCIM.md Updated to say OAuth 2.0 is required for authentication and authorization --- IL1-SCIM.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index d75483e..6f914b3 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -40,7 +40,7 @@ Identity Services SHALL integrate with the Application's SCIM endpoint using OAu ### 3.2.1 General Requirements * The Identity Service SHALL implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. * The Application SHALL implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. -* All SCIM operations SHALL be authenticated via OAuth 2.0; local modifications are prohibited. +* All SCIM operations SHALL be authenticated and authorized via OAuth 2.0; local modifications are prohibited. ### 3.2.2 User Provisioning Operations The Application MUST provide support all User provisioning operations defined in this section. From ebe01f9c7e8f886e9e0f4b5986ac322d9c8f529c Mon Sep 17 00:00:00 2001 From: Jennifer Winer Date: Sun, 20 Jul 2025 20:19:09 +0100 Subject: [PATCH 13/16] initial review with todos --- IL1-SCIM.md | 266 ++++++++++++++++++++++++++++++++++------------------ 1 file changed, 176 insertions(+), 90 deletions(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 6f914b3..a8861cd 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -1,68 +1,143 @@ -# Abstract -The IPSIE IL1 SCIM 2.0 Profile defines a profile of SCIM 2.0 intended to meet the security and interoperability requirements of enterprise integrations using SCIM. It establishes a clear baseline for provisioning and lifecycle management of enterprise users and the roles those users are assigned. The IL1 specification ensures that CRUD operations initiate from the Identity Service and that local modifications within the Application do not occur. - - -# 1.0 Introduction -This document defines the IPSIE Identity Lifecycle 1 (SL1) Profile for SCIM 2.0. It provides a clear reference for SCIM deployments that require a well-defined security baseline meeting best practices for interoperable enterprise identity management. +--- +title: IPSIE IL1 SCIM 2.0 Profile - draft + +ipr: none +cat: std +wg: IPSIE + +coding: us-ascii +pi: + toc: yes + sortrefs: yes + symrefs: yes + private: yes + +author: + - + ins: M. Maguire + name: Mark Maguire + org: Aujas Cybersecurity + email: mark.maguire@aujas.com + - + ins: J. Schreiber + name: Jen Schreiber + org: Workday + email: jennifer.winer@workday.com +normative: + ISODIR2: + RFC7523: + RFC7643: + RFC7644: + RFC6749: + RFC8414: + +--- abstract + +This document defines a profile for SCIM 2.0 to meet the security and interoperability requirements for identity lifecycle management within enterprises. Within the context of SCIM, The profile establishes requirements for provisioning, account management, client authentication, and identity synchronization. + +--- middle + +## Introduction + +This document defines the IPSIE Identity Lifecycle 1 (IL1) Profile for SCIM 2.0. It provides a clear reference for SCIM deployments that require a well-defined security baseline meeting best practices for interoperable enterprise identity management. The profile addresses critical aspects of secure identity management, with particular emphasis on: -* Client Authentication -* Creation, Update, and Deletion of accounts + +* Client authentication +* Creation, update, and deletion of users * Synchronization of data from the Identity Service to the Application By adhering to this profile, organizations can implement SCIM-based integrations that meet stringent security requirements while ensuring interoperability across different implementations. -# 2.0 Conventions and Definitions -The keywords "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "CAN" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings. + CRUD events and lifecycle management of enterprise users and their assigned roles. The IL1 profile ensures that CRUD operations initiate from the Identity Service and that local modifications within the Application do not occur. + +## Conventions and Definitions + +The keywords "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "CAN" in this document are to be interpreted as described in ISO Directive Part 2 {{ISODIR2}}. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings. + +### Terminology + +SCIM +> The System for Cross-domain Identity Management as defined in {{RFC7643}} and {{RFC7644}} + +SCIM Client +> An application that uses the SCIM protocol to manage identity data maintained by the service provider. The client initiates SCIM HTTP requests to +a target service provider. + +SCIM Service Provider +> An HTTP web application that provides identity information via the SCIM protocol. + +Role +> + +Identity Service +> Acts as the SCIM client, initiating all provisioning operations. +Application +> Acts as the SCIM service provider, hosting SCIM endpoints and processing all provisioning requests. -## 2.1 Terminology -The terms "SCIM", "SCIM Client", and "SCIM Service" refer to the terminology defined in [RFC 7644]. +Note: When SCIM is applied to the context of IPISIE, the Identity Service acts as the SCIM client and the Application acts as the SCIM service provider. The document will use the Role terms below for consistency between across IPSIE Profiles. -## 2.2 Roles -* **Identity Service**: Acts as the SCIM Client, initiating all provisioning operations. -* **Application**: Acts as the SCIM Service, hosting SCIM endpoints and processing all provisioning requests. +## Profile +### Authentication and Authorization {#authn-authz} -# 3.0 Profile +The Identity Service and Application MUST use OAuth 2.0 {{RFC6749}} for authentication and authorization of SCIM protocol. -## 3.1 OAuth 2.0 Requirements -Identity Services SHALL integrate with the Application's SCIM endpoint using OAuth 2.0 for secure authorization and token-based authentication. The following requirements ensure consistent and secure handling of access tokens and authorization server configuration: -* OAuth 2.0 interactions must comply with JWT Client Authentication as defined in RFC 7523. +// TODO: Should this limk back to SL1? +// TODO: Expand Section + +The following requirements ensure consistent and secure handling of access tokens and authorization server configuration: + +// TODO: Be more explicit with token names. + +* OAuth 2.0 interactions MUST comply with JWT Client Authentication as defined in {{RFC7523}} * The token SHALL exchange a signed JWT for an access token and present that token in the {Authorization: Bearer} header on all subsequent SCIM requests. -* The token must be scoped to "scim" and not grant broader permissions. -* The token must contain a "token_endpoint" value which is the URL of the Application Provider's OAuth 2.0 token endpoint. -* All Authorization Server parameters SHOULD be discovered from OAuth Authorization Server metadata as defined in RFC 8414. +* The token MUST contain a "token_endpoint" value which is the URL of the Identity Service's OAuth 2.0 token endpoint. +* The Acess Token MUST include the "scim" scope and not grant broader permissions. +* All Authorization Server parameters SHOULD be discovered from OAuth Authorization Server metadata as defined in {{RFC8414}}. * The Identity Service SHOULD expose a jwks_uri to allow the Application to perform signature verification -## 3.2 SCIM Interoperability Requirements +### SCIM Interoperability Requirements + +#### General Requirements + +* The Identity Service SHALL implement the required functionality of a SCIM client as defined in {{RFC7643}} and {{RFC7644}}. +* The Application SHALL implement the required functionality of a SCIM service provider as defined in {{RFC7643}} and {{RFC7644}}. +* All SCIM operations SHALL be authenticated and authorized via OAuth 2.0 as specified in {{authn-authz}}. +* Local modifications are prohibited. + +// TODO: Local modificaitons? -### 3.2.1 General Requirements -* The Identity Service SHALL implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. -* The Application SHALL implement the required functionality of a SCIM Client as defined in RFC 7643 and RFC 7644. -* All SCIM operations SHALL be authenticated and authorized via OAuth 2.0; local modifications are prohibited. +#### User Provisioning Operations -### 3.2.2 User Provisioning Operations The Application MUST provide support all User provisioning operations defined in this section. -#### 3.2.3 Create User (POST /Users) -User creation is performed by the SCIM operation POST /Users +##### Create User (POST /Users) + +User creation is performed by the SCIM operation POST /Users. + +In addition to the user attributes required by {{RFC7643}}, the following attributes are required to be part of the User schema: + +// TODO: Should we keep this vauge or refer be explicit with attributes we are requiring? email vs emails? -In addition to the user attributes required by RFC 7643, the following attributes are required to be part of the account schema: * An attribute which contains a unique identifier used by the enterprise to distinguish the owner of the account, such as "externalId." * An attribute which contains the primary email address of the user, such as "email" -#### 3.2.4 Update User (PATCH /Users/{id}) -User updates are performed via the SCIM operation: PATCH /Users/{id} +##### Update User (PATCH /Users/{id}) + +User updates are performed by the SCIM operation PATCH /Users/{id} + +##### Deactivate or Reactivate User (PATCH /Users/{id}) -#### 3.2.5 Deactivate or Reactivate User (PATCH /Users/{id}) -Changes to the user activation status are performed via the SCIM operation: PATCH /Users/{id} +Changes to the user activation status, such deactivation and reactivation, are performed by the SCIM operation PATCH /Users/{id} The Identity Service SHOULD propagate user deactivation events to the Application within 5 minutes of the user being deactivated. -The Application SHOULD respond to user deactivation events by revoking the ability for the user to continue accessing the Application, including the revocation of currently active sessions. The revocation mechanism is an implementation detail outside the scope of this specification. Revocation SHOULD occur within 5 minutes of receiving the deactivation. +The Application SHOULD respond to user deactivation events by revoking the ability for the user to continue accessing the Application, including the revocation of currently active sessions. The revocation mechanism outside the scope of this profile. Revocation SHOULD occur within 5 minutes of receiving the deactivation request. + +When a user account is deactivated, all access mechanisms and authorizations associated with that account MUST also be deactivated. This includes, but is not limited to: -When a user account is deactivated, all access mechanisms and authorizations associated with that account must also be deactivated. This includes, but is not limited to: * Web sessions * API tokens * Refresh tokens @@ -70,108 +145,119 @@ When a user account is deactivated, all access mechanisms and authorizations ass * SSH keys associated with the user * Device-based authentication credentials -The Application MUST allow reactivation of a deactivated user. +The Application MUST allow reactivation of a deactivated user. + +##### Delete User (DELETE /Users/{id}) + +User deletions are performed by the SCIM operation DELETE /Users/{id} -#### 3.2.6 Delete User (DELETE /Users/{id}) -User deletions are performed via the SCIM operation: DELETE /Users/{id} +After a user is deleted, the Application MUST allow the creation of a new user with the same username. +// TODO: this could be tricky RE: maintianing the user's data -After a user is deleted, Application MUST allow the creation of a new user with the same username. +##### Get All Users (GET /Users) -#### 3.2.7 Get All Users (GET /Users) -A search for all users in the system are performed by the SCIM operation: GET /Users +Get all users in the system is performed by the SCIM operation GET /Users -This endpoint ensures that any accounts which were made by a Just-in-Time (JIT) provisioning action can be managed by the Identity Service. +This endpoint ensures that all users are managed by the Identity Service. To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Users request. To ensure system stability and prevent abuse, the Application SHALL enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. -#### 3.2.8 Get User By ID (GET /Users/{id}) -User searches by id are performed via the SCIM operation: GET /Users/{id} +##### Get User By ID (GET /Users/{id}) + +User searches by id are performed by the SCIM operation GET /Users/{id} + +##### List Users By Alternate Identifier (GET /Users?) -#### 3.2.9 List Users By Alternate Identifier (GET /Users?) User searches by alternate identifier are performed via the SCIM operation: GET /Users?filter={filterExpression} Application Providers MUST support the following filter expressions: + * username eq {username} * externalId eq {externalId} * emails[value eq {email}] -### 3.3 Group (Role) Provisioning Operations +#### Group (Role) Provisioning Operations + The Application MUST provide support all Group provisioning operations defined in this section. **Note**: Within the IPSIE standard, Application permissions are referred to as "Roles." Within SCIM, Application permissions are referred to as "Groups." The term "Role" in IPSIE is functionally equivalent to the term "Group" in SCIM. -#### 3.3.1 Get All Groups (GET /Groups) -A search for all groups in the system are performed by the SCIM operation: GET /Groups +##### Get All Groups (GET /Groups) + +A search for all groups in the system is performed by the SCIM operation GET /Groups -This endpoint ensures that any all groups can be managed by the Identity Service. +This endpoint ensures that all groups are managed by the Identity Service. To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Application SHALL enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. -#### 3.3.2 Get Group By ID (GET /Group/{id}) -Group searches by id are performed via the SCIM operation: GET /Group/{id}?excludedAttributes=members +##### Get Group By ID (GET /Group/{id}) + +Group searches by id are performed by the SCIM operation GET /Group/{id}?excludedAttributes=members + +##### List Groups By Alternate Identifier (GET /Groups?) + +User lookups by alternate identifier are performed by the SCIM operation GET /Groups?filter={filterExpression}&excludedAttributes=members -#### 3.3.3 List Groups By Alternate Identifier (GET /Groups?) -User lookups by alternate identifier are performed via the SCIM operation: GET /Groups?filter={filterExpression}&excludedAttributes=members +##### Add or Remove Group Members (PATCH /Group/{id}) -#### 3.3.4 Add or Remove Group Members (PATCH /Group/{id}) -Members are added or removed from Groups via the SCIM operation: PATCH /Groups/{id} +Members are added or removed from Groups via the SCIM operation PATCH /Groups/{id} For each Operation in the PATCH: The op attribute MUST contain either "add" or "remove". + * When the op is "add": - * The path attribute MUST be "members". - * The value attribute MUST be an array of Group member elements, as defined in Section 4.2 of the SCIM Core Schema [RFC7643]. Each member MUST contain a value subattribute with the id of the resource being added to the group. + * The path attribute MUST be "members". + * The value attribute MUST be an array of Group member elements, as defined in Section 4.2 of the SCIM Core Schema {{RFC7643}}. Each member MUST contain a value subattribute with the id of the resource being added to the group. * When the op is "remove": - * The path attribute MUST be either: - * "members" (to remove all members) - * "members[value eq \"{id}\"]" (to remove a single member) - * The value attribute MUST be unspecified. + * The path attribute MUST be either: + * "members" (to remove all members) + * "members[value eq \"{id}\"]" (to remove a single member) + * The value attribute MUST be unspecified. + +### Metadata Endpoints + +#### ResourceTypes -### 3.4 Metadata Endpoints +Application MUST host a /ResourceTypes endpoint, as defined in Section 4 of {{RFC7644}}. -#### 3.4.1 /ResourceTypes -Application MUST host a /ResourceTypes endpoint, as defined in Section 4 of RFC 7644. +The supported ResourceTypes MUST include Users and Groups. -The supported ResourceTypes MUST include Users and Groups. +#### ServiceProviderConfig -#### 3.4.2 /ServiceProviderConfig -Application Providers MUST host a /ServiceProviderConfig endpoint to describe the operations they support, as defined in Section 4 of RFC 7644. +Application Providers MUST host a /ServiceProviderConfig endpoint to describe the operations they support, as defined in Section 4 of {{RFC7644}} The operations MUST include, at minimum, the set of SCIM capabilities required for compatibility with this IPSIE profile. -#### 3.4.3 /Schemas -Application Providers MUST host a /Schemas endpoint to describe the supported schemas, as defined in Section 4 of RFC 7644. There must be a schema for both Users and Groups. The schemas must include all required attributes from RFC 7643 and from Section 3.2.3 (Create User). +#### Schemas + +Application Providers MUST host a /Schemas endpoint to describe the supported schemas, as defined in Section 4 of {{RFC7644}}. There must be a schema for both Users and Groups. The schemas must include all required attributes from RFC 7643 and from Section 3.2.3 (Create User). + +### Security Considerations -# 4.0 Security Considerations -For SCIM security considerations, see RFC 7643 and RFC 7644. +For SCIM security considerations, see {{RFC7643}} and {{RFC7644}} + +Additionally, the following requierements are included to address security considerations. -Additionally, the following security considerations must be included: * **Transport Security**: All endpoints SHALL enforce TLS 1.2 or later with strong cipher suites and certificate validation. * **Error Handling**: Error responses SHALL use the SCIM error format and SHALL NOT leak internal details. * **Replay Resistance**: Access tokens SHALL expire and nonces SHALL be validated to prevent replay. * **Auditing**: All provisioning actions and responses SHALL be logged for audit and troubleshooting. * **Rate Limiting**: All endpoints SHALL enforce rate limiting and must respond with "429 Too Many Requests" when limits are exceeded. -# 5.0 Compliance Statement +## Compliance Statement + Implementation of all mandatory requirements in this profile will result in a SCIM 2.0 deployment that satisfies IPSIE Identity Lifecycle Level 1 (IL1). Specifically: -* **Identity Service (SCIM Client)** - * SHALL initiate all CRUD operations for Users and Groups. +* **Identity Service (SCIM client)** + * SHALL initiate all CRUD operations for Users and Groups. + * SHALL adhere to the security considerations above. -* **Application (SCIM Service)** - * SHALL host all SCIM endpoints with full support for User and Group provisioning. - * SHALL prevent local modifications outside of SCIM. - * SHALL enforce OAuth 2.0 JWT Profile for authentication and adhere to the security considerations above. +* **Application (SCIM service provider)** + * SHALL host all SCIM endpoints with full support for User and Group provisioning. + * SHALL prevent local modifications outside of SCIM. + * SHALL enforce OAuth 2.0 JWT Profile for Authentication {{RFC7523}}. + * SHALL adhere to the security considerations above. By conforming to this profile, implementations will achieve a consistent, secure, and interoperable baseline for enterprise identity lifecycle management. - -## 6.0 Normative References -TODO - -## 7.0 Acknowledgements -TODO - -## 8.0 Author's Address -TODO From 50afcc08b2634b66711db44040fe23bce37770fd Mon Sep 17 00:00:00 2001 From: Jennifer Winer Date: Sun, 20 Jul 2025 20:31:19 +0100 Subject: [PATCH 14/16] add create groups --- IL1-SCIM.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index a8861cd..734d018 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -44,13 +44,12 @@ This document defines the IPSIE Identity Lifecycle 1 (IL1) Profile for SCIM 2.0. The profile addresses critical aspects of secure identity management, with particular emphasis on: * Client authentication -* Creation, update, and deletion of users +* Retrieve, add, and modify Users. +* Retrieve, add, and modify Groups. * Synchronization of data from the Identity Service to the Application By adhering to this profile, organizations can implement SCIM-based integrations that meet stringent security requirements while ensuring interoperability across different implementations. - CRUD events and lifecycle management of enterprise users and their assigned roles. The IL1 profile ensures that CRUD operations initiate from the Identity Service and that local modifications within the Application do not occur. - ## Conventions and Definitions The keywords "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "CAN" in this document are to be interpreted as described in ISO Directive Part 2 {{ISODIR2}}. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings. @@ -68,7 +67,7 @@ SCIM Service Provider > An HTTP web application that provides identity information via the SCIM protocol. Role -> +> TODO: Add definition Identity Service > Acts as the SCIM client, initiating all provisioning operations. @@ -84,7 +83,7 @@ Note: When SCIM is applied to the context of IPISIE, the Identity Service acts a The Identity Service and Application MUST use OAuth 2.0 {{RFC6749}} for authentication and authorization of SCIM protocol. -// TODO: Should this limk back to SL1? +// TODO: Should this link back to SL1? // TODO: Expand Section The following requirements ensure consistent and secure handling of access tokens and authorization server configuration: @@ -105,9 +104,7 @@ The following requirements ensure consistent and secure handling of access toke * The Identity Service SHALL implement the required functionality of a SCIM client as defined in {{RFC7643}} and {{RFC7644}}. * The Application SHALL implement the required functionality of a SCIM service provider as defined in {{RFC7643}} and {{RFC7644}}. * All SCIM operations SHALL be authenticated and authorized via OAuth 2.0 as specified in {{authn-authz}}. -* Local modifications are prohibited. - -// TODO: Local modificaitons? +* Local modifications to Users or Groups in the Application are prohibited. #### User Provisioning Operations @@ -182,6 +179,12 @@ The Application MUST provide support all Group provisioning operations defined i **Note**: Within the IPSIE standard, Application permissions are referred to as "Roles." Within SCIM, Application permissions are referred to as "Groups." The term "Role" in IPSIE is functionally equivalent to the term "Group" in SCIM. +##### Create Group (POST /Groups) + +Group creation is performed by the SCIM operation POST /Group. + +// TODO: Add more details + ##### Get All Groups (GET /Groups) A search for all groups in the system is performed by the SCIM operation GET /Groups From 80e7f22873cf46c6bc238b085fda98d46450955b Mon Sep 17 00:00:00 2001 From: Jennifer Winer Date: Sun, 20 Jul 2025 20:34:26 +0100 Subject: [PATCH 15/16] add filter requirement for groups --- IL1-SCIM.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 734d018..43eb5c3 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -201,6 +201,10 @@ Group searches by id are performed by the SCIM operation GET /Group/{id}?exclude User lookups by alternate identifier are performed by the SCIM operation GET /Groups?filter={filterExpression}&excludedAttributes=members +Application Providers MUST support the following filter expressions: + +// TODO: Add what filters are required to be supported + ##### Add or Remove Group Members (PATCH /Group/{id}) Members are added or removed from Groups via the SCIM operation PATCH /Groups/{id} From 4c5c6050bc7a5ee2866a80e2ce0b12fa0b3d60e6 Mon Sep 17 00:00:00 2001 From: Jennifer Winer Date: Sun, 20 Jul 2025 20:37:53 +0100 Subject: [PATCH 16/16] capitalization --- IL1-SCIM.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/IL1-SCIM.md b/IL1-SCIM.md index 43eb5c3..25f916c 100644 --- a/IL1-SCIM.md +++ b/IL1-SCIM.md @@ -191,7 +191,7 @@ A search for all groups in the system is performed by the SCIM operation GET /Gr This endpoint ensures that all groups are managed by the Identity Service. -To ensure that large amounts of data can be read from the Application, the application must support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Application SHALL enforce rate limits on this endpoint and must respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. +To ensure that large amounts of data can be read from the Application, the application MUST support with index-based or cursor-based pagination for the GET /Groups request. To ensure system stability and prevent abuse, the Application SHALL enforce rate limits on this endpoint and MUST respond with appropriate headers, such as "429 Too Many Requests" and "Retry-After," when limits are exceeded. ##### Get Group By ID (GET /Group/{id})