Create IL1-SCIM.md #72

2MarkMaguire · 2025-05-02T20:08:53Z

First draft of SCIM 2.0 profile for IPSIE IL1

mcguinness · 2025-05-03T05:25:22Z

IL1-SCIM.md

+
+# 3.0 Profile
+
+## 3.1 Client Authentication


Recommend we follow similar approach to CAEP Interoperability Profile 1.0 https://openid.github.io/sharedsignals/openid-caep-interoperability-profile-1_0.html and have OAuth requirements in its own section

I think we should take a dependency on Protected Resource Server Metadata RFC 9728 and Authorization Server Metadata RFC 8414 for discovery of most of the OAuth parameters needed to obtain an access_token for the SCIM Server.

SCIM Server must always publish the following in the PRM

Only 1 Authorization Server (constraint for simplification we can revisit)

Scopes required for the SCIM Server (e.g. both read and manage)

Bearer method supported of header

CAEP interop also defined fallback scopes as PRM was optional. If we don't want to take the dependency on PRM then I would advocate for both a read and manage scope similar to SSF.

I am assuming you intended to support JWT Client Authentication with RFC 7523 and not JWT Authorization Grant. It's currently ambiguous

Only supporting client authentication with JWT assertion adds a lot more deployment friction especially for a multi-tenant deployments IMHO. The Identity Service would more than likely need to register a client credential per-RP tenant out-of-band and couldn't reuse a common registration across tenants as their is no consent flow to authorize the instance. This often a blocker that needs its own human in the loop workflow when onboarding SCIM for an app.

The benefit of authorization code flow is the Identity Server can ask the admin to delegate access at runtime with minimal configuration needed with a shared client registration. The drawback being that operations are performed as the user being delegated and access would be revoked when the user who delegated access is revoked or deactivated.

The use of JWT as Authorization Grant could be interesting if we wanted to profile this as I think we would need to solve a tenant claim for both the OP and RP. This would more than likely be something we need to do outside of IPSIE.

mcguinness · 2025-05-03T05:43:31Z

IL1-SCIM.md

+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.


All of the Authorization Server parameters should be discovered from OAuth Authorization Server metadata

mcguinness · 2025-05-03T06:26:00Z

IL1-SCIM.md

+* 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


I was thinking we would have the required lifecycle operations defined for IPSIE then this document just maps the IPSIE operation to a protocol-specific operation. The IPSIE lifecycle operation would be based on something like ISO/IEC 24760-1:2019 vs REST verbs.

So for example:

Enroll User -> Create User Resource (POST /Users)
Activate User -> Modify User Resource (PATCH /User/:id)
Maintain User -> Modify User Resource (PATCH /User/:id)
Suspend User -> Modify User Resource (PATCH /User/:id)
Deactivate User -> Modify User Resource (PATCH /User/:id)
Reactivate User -> Modify User Resource (PATCH /User/:id)
Delete User -> Delete User Resource (DELETE /User/:id)

mcguinness · 2025-05-04T05:57:32Z

IL1-SCIM.md

+
+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.


I think we need to be more opinionated here in IPSIE. Deactivation needs to revoke ALL access for user.

We should also look at the revocation as a SLO as you noted above, @mcguinness.

I disagree here. Frequently lifecycle events for large companies are 2 steps:

Disable

(2 weeks later) Delete

When HR accidentally terms someone (and it happens all the time), this allows for their accounts to be reenabled without forcing all access to be rerequested.

I think if we require all access to be removed on disable then it becomes over-prescriptive and removes enterprises freedom to choose what works best for them.

We might need better language but my intent was to ensure all access was revoked not that the account was deleted or permissions were revoked. Suspending an account needs to have stronger guarantee on what is revoked (e.g web sessions, refresh tokens, api tokens, and personal access tokens).

mcguinness · 2025-05-04T05:58:04Z

IL1-SCIM.md

+
+The Application MUST allow reactivation of a deactivated user. 
+
+#### 3.2.6 Delete User (DELETE /Users/{id})


Can you delete an active user?

Its a good question. I would say yes - but I think this is something we should standardize with IPSIE

Deactivate then Delete IMHO seems to align better with what I have seen in the wild. This enables access state to revoked during deactivation then database relationships such as group memberships to be removed during delete.

mcguinness · 2025-05-04T06:02:11Z

IL1-SCIM.md

+#### 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.


Is this something that would change at different levels? Service Level Objective (SLO) targets feel like something that would make more sense at the IPSIE level vs at the protocol level if we want to define these.

Maybe the best way to handle this is to introduce SLOs in IPSIE IL3 and for SCIM IL1 Profile we can cut the "5 min" requirements

mcguinness · 2025-05-04T06:06:17Z

IL1-SCIM.md

+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


Is there any required attributes or constraints we need to enforce?

Should externalId be set to the same value as the assertion subject identifier?

Should email or userName be required to enable account linking if there is no externalId?

Should active be required to support lifecycle operations needed by IPSIE

Should we define standard mappings for SAML and OIDC schemas to SCIM?

Should we explicitly disallow the use of password? I know Okta sets this value to a secure random in case the app supports a backdoor login mechanism outside of SSO

We need to discuss whether or not to use standard naming conventions or to provide a mapping to allow client and server to discover the naming conventions used by the other and map fields accordingly. Right now SCIM leaves this too open ended leading to interop challenges. I look forward to hearing others' thoughts on the best path forward.

My worry with making attribute names standardized is it killing adoption. Maybe thats something we introduce at IL2/IL3?

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 required.

mcguinness · 2025-05-04T06:10:33Z

IL1-SCIM.md

+### 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.


I had a different understanding. Groups may act as Roles but Apps are free to have Groups and Roles as separate entities. Groups can be assigned to Roles but so can individual users.

We'll also get into the discussion of entitlements, further muddying the terminology if we're not careful. At IETF122 @aaronpk mentioned that the entitlements draft was being resurrected. I've seen no updates yet.

Based on the IPSIE IL definitions, my understanding is that "Role" is the term used for any application permissions - role does not mean bundling of numerous permissions together (although that is a common definition - role and group are both overloaded terms. I maintain "Entitlement" is a better choice than either, but that would require us updating the IPSIE IL definition)

mcguinness · 2025-05-04T06:16:52Z

IL1-SCIM.md

+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}


Any requirements needed for users that were created via SSO JIT but now need to be managed identities via SCIM?

Since IPSIE says nothing about the JIT process, we need a way to discover these users via SCIM, and then put them under management by SCIM.

mcguinness · 2025-05-04T06:29:33Z

IL1-SCIM.md

+* 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


For brownfield apps, the Identity Service often needs to audit the RP by importing and reconciling the existing identities in the app with the identities in the IdP. This requires paging through all the users and groups. We should define the mechanism a SCIM Server must support for an Identity Service to import/audit large user or group collections. There are several SCIM extensions that could be useful but today are not guaranteed. This is a huge interop challenge today.

Agreed. The cursor based pagination work will be helpful here, but we really need to work with the SCIM WG to drive the delta-query mechanism to completion. Scaling SCIM demands improved tooling for anti-entropy mechanisms.

Completely agree

Delta Query puts a lot of implementation requirements on the RP. I think SL1 should just support cursor paged pagination with lastUpdated timestamps and standardize how rate limits should work. This should significantly address the interop gaps while providing a lowest level in implementation requirements for the RO

mcguinness · 2025-05-06T07:12:32Z

IL1-SCIM.md

+* externalId eq {externalId}
+* emails[value eq {email}]
+
+### 3.3 Group (Role) Provisioning Operations


Need to define audit operation to list all members of a group and how to handle large datasets (e.g page). Identity Server needs to onboard brownfield app as well as ensure no drift between system of record and app

Need to define how to remove a group (e.g https://openid.net/specs/fastfed-scim-1_0-02.html#SCIMInteroperabilityGroupProvisioningDeactivateGroup)

mcguinness · 2025-05-06T07:12:59Z

IL1-SCIM.md

+# 4.0 Security Considerations
+For SCIM security considerations, see RFC 7643 and RFC 7644. 
+
+Additionally, the following security considerations must be included:


Need to define interoperability for rate-limiting

mcguinness · 2025-05-06T07:14:20Z

IL1-SCIM.md

+
+The operations MUST include, at minimum, the set of SCIM capabilities required for compatibility with this IPSIE profile.
+
+#### 3.4.3 /Schemas


Need to define schemas that are required such as Enterprise User

dhs-BI · 2025-05-06T15:09:47Z

IL1-SCIM.md

+
+# 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.
+


We'll want to normalize these to IETF style language using uppercase terminology in a future version.

dhs-BI · 2025-05-06T15:11:13Z

IL1-SCIM.md

+## 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.
+


Although SCIM uses these terms, there's a draft of use cases that covers a much richer set of interaction styles. We should consider whether or not to include references to those more complex patterns here as well. https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases-reloaded/

dhs-BI · 2025-05-06T15:12:49Z

IL1-SCIM.md

+* 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.
+


s/authenticated/authorized/ on line 42

Create IL1-SCIM.md

e1d38b4

dhs-BI requested review from aaronpk and dhs-BI May 2, 2025 20:10

dhs-BI added the il1 label May 2, 2025

mcguinness reviewed May 3, 2025

View reviewed changes

mcguinness reviewed May 4, 2025

View reviewed changes

mcguinness reviewed May 6, 2025

View reviewed changes

dhs-BI reviewed May 6, 2025

View reviewed changes

dhs-BI mentioned this pull request May 8, 2025

FAL2 - storage of subscriber attributes/deprovisioning #83

Open


		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})


		The operations MUST include, at minimum, the set of SCIM capabilities required for compatibility with this IPSIE profile.

		#### 3.4.3 /Schemas


		# 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.

Create IL1-SCIM.md #72

Are you sure you want to change the base?

Create IL1-SCIM.md #72

Uh oh!

Conversation

2MarkMaguire commented May 2, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcguinness May 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcguinness May 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

mcguinness May 4, 2025 •

edited

Loading

mcguinness May 4, 2025 •

edited

Loading