SCIM P. Hunt, Ed.
Internet-Draft IndependentId
Obsoletes: draft-hunt-idevent-scim-01 (if N. Cam-Winget
approved) Cisco Systems
Intended status: Standards Track 20 January 2023
Expires: 24 July 2023
SCIM Profile for Security Event Tokens
draft-ietf-scim-events-01
Abstract
This specification defines a set of Security Event types using the
Security Event Token format (RFC8417). These events can be used
across domains by SCIM Service Providers and receivers to exchange
security event signals used for: request confirmations, replication,
provisioning co-ordination, and security signals.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 July 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hunt & Cam-Winget Expires 24 July 2023 [Page 1]
Internet-Draft draft-ietf-scim-events January 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. SCIM Events . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Identifying the Subject of an Event . . . . . . . . . . . 6
2.2. Common Event Attributes . . . . . . . . . . . . . . . . . 7
2.3. SCIM Feed Events . . . . . . . . . . . . . . . . . . . . 8
2.3.1. urn:ietf:params:event:SCIM:feed:add . . . . . . . . . 8
2.3.2. urn:ietf:params:event:SCIM:feed:remove . . . . . . . 8
2.4. SCIM Provisioning Events . . . . . . . . . . . . . . . . 9
2.4.1. urn:ietf:params:event:SCIM:prov:create . . . . . . . 9
2.4.2. urn:ietf:params:event:SCIM:prov:patch . . . . . . . . 11
2.4.3. urn:ietf:params:event:SCIM:prov:put . . . . . . . . . 13
2.4.4. urn:ietf:params:event:SCIM:prov:delete . . . . . . . 15
2.4.5. urn:ietf:params:event:SCIM:prov:activate . . . . . . 16
2.4.6. urn:ietf:params:event:SCIM:prov:deactivate . . . . . 16
2.5. SCIM Signals Events . . . . . . . . . . . . . . . . . . . 16
2.5.1. urn:ietf:params:event:SCIM:sig:authMethod . . . . . . 16
2.5.2. urn:ietf:params:event:SCIM:sig:pwdReset . . . . . . . 17
2.6. Miscellaneous Events . . . . . . . . . . . . . . . . . . 17
2.6.1. urn:ietf:params:event:SCIM:misc:asyncResp . . . . . . 18
3. Event Delivery . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. Security Event Token Signing and Encryption . . . . . . . 20
3.2. Point-to-Point Delivery Over HTTP . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 27
A.1. Domain Based Replication . . . . . . . . . . . . . . . . 27
A.2. Co-ordinated Provisioning . . . . . . . . . . . . . . . . 28
A.3. Risk Signals . . . . . . . . . . . . . . . . . . . . . . 30
A.4. Async Requests . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 32
Hunt & Cam-Winget Expires 24 July 2023 [Page 2]
Internet-Draft draft-ietf-scim-events January 2023
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction and Overview
This specification defines Security Events for SCIM service providers
and receivers as specified by the Security Event Tokens (SET)
[RFC8417] specificaiton. These events include: asynchronous
transaction confirmations, replication, provisioning co-ordination,
and security signals.
In a typical HTTP client-server relationship a SCIM Protocol Client
issues commands to a SCIM Server using HTTP methods such as GET,
POST, PATCH, and DELETE [RFC7644] in many cases to effect a state
change. Subsequently, when multiple SCIM protocol client entities
update SCIM resources, an individual client may need to be informed
of changes that occur over time. This may be achieved through the
use of event messages or signals in the form of Security Event Tokens
(SET). SET tokens convey information about changes that have occured
in a publishing domain that may be of interest to a receiving domain.
Unlike SCIM Protocol requests, Security Events do not describe
actions that a receiver must take, rather they are simple statements
of fact about changes that have already occurred. The intent, is to
allow the event receiver to determine the best follow-uip action to
take within the context of the receiving domain. This gives each
domain independent operation and control.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Notational Conventions
For purposes of readability examples are not URL encoded.
Implementers MUST percent encode URLs as described in Section 2.1 of
[RFC3986].
Throughout this documents all figures MAY contain spaces and extra
line-wrapping for readability and space limitations. Similarly, some
URI's contained within examples, have been shortened for space and
readability reasons.
Hunt & Cam-Winget Expires 24 July 2023 [Page 3]
Internet-Draft draft-ietf-scim-events January 2023
1.3. Definitions
This specification uses definitions from the following
specifications:
* Security Event Tokens [RFC8417], and
* System for Cross-Domain Identity Management Protocol [RFC7644].
Additionally, the following terms are defined:
Attributes and Claims
The JWT specification [RFC7519] upon which SET is based uses the
term "claims" to refer to attributes in a JSON token. SCIM in
contrast uses the term "attributes" to refer to JSON attributes.
For the purposes of this draft, the terms "attributes" and
"claims" are equivalent.
CP
Abbreviation for "Co-ordinated Provisioning" as defined in
Appendix A.2. In these relationships an Event Publisher and
Receiver typically exchange resource change events without
exchanging change data. For a receiver to know the value of the
data, the Event Receiver usually has to call back to the Event
Publisher domain to receive a new copy of data (e.g. Using a SCIM
GET request).
DBR
Abbreviation for "Domain Based Replication" as defined in
Appendix A.1. In this mode because there is an administrative
relationship spanning multiple operational domains, data shared in
Events typically includes all of the change data. This eliminates
the need for a call back (e.g. a SCIM GET request), to retrieve
raw data.
Event Feed
This describes the notion that a feed MAY be individualized per
client. A service provider MAY offer to allow Event Receiver's to
"subscribe" to specific event types or events about specific
resources. If no option is offered, it is assumed the client will
receive all events about all resources.
Hunt & Cam-Winget Expires 24 July 2023 [Page 4]
Internet-Draft draft-ietf-scim-events January 2023
Event Receiver
A service that receives events for the purpose of subsequent
action (e.g. such as replication), co-ordination of workflow, or
signalling. In the case of SET Push Transfer [RFC8935], the Event
Receiver is an HTTP Service Endpoint that receives requests. In
the case of SET Poll-Based Transfer [RFC8936], the receiver is an
HTTP client that initiates HTTP request to an Event Publisher
endpoint.
Event Publisher
A system that issues SETs based on a change that has occurred at a
SCIM Service Provider. For example, events MAY originate from a
SCIM Create, Modify, or Delete per [RFC7644] request. A SCIM
Service Provider MAY be an Event Publisher or an independent
service that aggregates events into Event Receiver feeds. As
described above, when using [RFC8935], the Event Publisher is an
HTTP Client that initiates HTTP POST requests to a defined Event
Receiver endpoint. When using [RFC8936], the Event Publisher
provides an HTTP endpoint which a receiver MAY use to "poll" for
Security Events.
RS
Abbreviation for "Risk Signals" as defined in Appendix A.3.
SCIM Client
An HTTP client that initiates SCIM Protocol [RFC7644] requests and
receives responses.
SCIM Service Provider
An HTTP server that implements SCIM Protocol [RFC7644] and SCIM
Schema [RFC7643].
SET
Abbreviation for "Security Event Token" as defined in [RFC8417]
2. SCIM Events
A SCIM event is a message, in the form of a Security Event Token
[RFC8417]. A SET event consists of a set of standard JWT "top-level"
claims, plus one or more Event Payload claims that contains
additional information relevant to a defined event.
Hunt & Cam-Winget Expires 24 July 2023 [Page 5]
Internet-Draft draft-ietf-scim-events January 2023
2.1. Identifying the Subject of an Event
SCIM Events SHALL use the "sub_id" claim defined by Subject
Identifiers for Security Event Tokens [SUBID] specification to
identify the subject of events. Since it is possible to issue a SCIM
SET Event with multiple events, the sub_id claim MUST NOT be
contained within an Event payload. A SET with multiple event URI's
SHALL indicate that the events originate from the same transaction or
resource state change. Finally, to distinguish SET Events from JWT
tokens, the JWT "sub" claim MUST NOT be used.
{
"iss": "issuer.example.com",
"iat": 1508184845,
"aud": "aud.example.com",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "alice@example.com"
},
"events": {
...
}
}
Figure 1: SCIM Subject Id Example
The top-level claim "sub_id" contains a sub-claim "format" whose
value is set to scim to indicate the other attributes present are
SCIM attributes. The following sub_id attributes are defined:
uri
The SCIM relative path for the resource which usually consists of
the resource type endpoint plus the resource id. For example
/Users/2b2f880af6674ac284bae9381673d462. This attributes MUST be
provided in a SCIM Event sub_id claim. Note the relative path is
the path component after the SCIM Service Provider Base URI as
defined in Section 1.3 [RFC7644]. In cases where the Event
Receiver is unable to match a URI, the Event Receiver MAY issue a
call-back to a previously agreedn SCIM Service Provider Base URI
plus the relative uri value and perform a SCIM GET request per
Section 3.4.1 [RFC7644].
externalId
If known, the externalId value of the SCIM Resource that MAY be
used by a receiver to identify the corresponding resource in the
Event Receiver's domain.
Hunt & Cam-Winget Expires 24 July 2023 [Page 6]
Internet-Draft draft-ietf-scim-events January 2023
id
The SCIM Id attribute MAY be used for backwards compatibility
reasons in addition to the uri claim.
emails,username, ...
A SCIM attribute which is uniquely identifiable (e.g. username,
emails). Used in situtations where the normal SCIM identifiers (
id and externalId) are insufficient to identfy a common resource
between an Event Publisher and Event Receiver.
2.2. Common Event Attributes
The following attributes are available for all events defined. Some
attributes are defined as SET/JWT claims, while others are "Event
Payload" claims as defined in Section 1.2 [RFC8417].
txn
For the purposes of SCIM, this SET defined "top-level" claim
identifies a unique transaction originating at a SCIM Service
Provider and/or its underlying data repository or database. The
claim is used to detect duplicate transactions that may have been
received (e.g. in the case of a re-transmitted or recovered
event). If not provided, the SET jti claim MAY be used. Where
txn identifies uniqueness within a SCIM Service Provider, multiple
SETs may be issued each with distinct JTI's stemming from a common
originating transaction with identical txn values.
data
Defined in SCIM Bulk Operations, Section 3.7 [RFC7644], thie
payload attribute contains the equivalent SCIM command processed
by the SCIM Service provider. For example, after processing a
SCIM Create operation, the data contained includes the final
representation of the created entity by the SCIM Service Provider
including the assigned id value.
attributes
This payload attribute contains an array of attributes that were
added, revised, or removed. For example:
"attributes": ["username","emails"]
Only one of data or attributes claims SHALL be provided depending on
the event definition.
This specifications defines a new URI prefix
urn:ietf:params:event:SCIM which is used as the prefix for the
following defined SCIM Events.
Hunt & Cam-Winget Expires 24 July 2023 [Page 7]
Internet-Draft draft-ietf-scim-events January 2023
2.3. SCIM Feed Events
This section defines events related to notices about which resources
are being added or removed from an event feed. These events are used
in Co-operative Provisioning scenarios where only a sub-set of
entities are shared across an Event Feed. The URI prefix for these
events is: urn:ietf:params:event:SCIM:feed
2.3.1. urn:ietf:params:event:SCIM:feed:add
The specified resource was added to the Event Feed. A feed:add does
not indicate a resource is new or has been recently created. For
example, an existing user has had a new role (e.g. CRM_User) added
to their profile which has caused their resource to join a feed.
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"txn": "b7b953f11cc6489bbfb87834747cc4c1",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jdoe"
},
"events":{
"urn:ietf:params:event:SCIM:feed:add": {}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 2: Example SCIM Feed Add Event
2.3.2. urn:ietf:params:event:SCIM:feed:remove
The specified resource has been removed from the feed. Removal does
not indicate that the resource was deleted or otherwise deactivated.
This event has minimal disclosure.
Hunt & Cam-Winget Expires 24 July 2023 [Page 8]
Internet-Draft draft-ietf-scim-events January 2023
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462"
"externalId": "jdoe",
},
"events":{
"urn:ietf:params:event:SCIM:feed:remove": {}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 3: Example SCIM Feed Remove Event
2.4. SCIM Provisioning Events
This section defines provisioning events that have occurred within a
SCIM Service Provider. These events are used in both Domain Based
Replication (DBR) and Co-operative Provisioning (CP) mode. The URI
prefix for these events is: urn:ietf:params:event:SCIM:prov
2.4.1. urn:ietf:params:event:SCIM:prov:create
Indicates a new SCIM resource has been created by the SCIM Service
Provider and has been added to the Event Feed. Note that when a
create event is sent, a corresponding
urn:ietf:params:event:SCIM:feed:add event SHOULD NOT be issued in the
same feed. In DBR mode mode, all claims of the new resource are
included. In CP mode, the attributes returned discloses what
attributes were created at the publisher. In DBR mode, the set of
values reflecting the final state of the resource at the service
provider are provided using the "data" attribute. Note that because
this is a replication request, the uri attribute that was assigned by
the SCIM Service Provider is shared so that all replicas in the
domain use the same resource identifier.
Hunt & Cam-Winget Expires 24 July 2023 [Page 9]
Internet-Draft draft-ietf-scim-events January 2023
{
"jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
],
"sub_id": {
"format": "scim",
"uri": "/Users/44f6142df96bd6ab61e7521d9",
"externalId":"jdoe"
}
"events":{
"urn:ietf:params:event:SCIM:prov:create":{
"data":{
"schemas":[ "urn:ietf:params:scim:schemas:core:2.0:User"],
"emails":[
{"type":"work","value":"jdoe@example.com"}
],
"userName":"jdoe",
"name":{
"givenName":"John",
"familyName":"Doe"
}
}
}
}
}
Figure 4: Example SCIM Create (Domain Replication Mode)
Hunt & Cam-Winget Expires 24 July 2023 [Page 10]
Internet-Draft draft-ietf-scim-events January 2023
{
"jti": "4d3559ec67504aaba65d40b0363faad8",
"iat": 1458496404,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://scim.example.com/Feeds/5d7604516b1d08641d7676ee7"
],
"sub_id": {
"format": "scim",
"uri": "/Users/44f6142df96bd6ab61e7521d9",
"externalId": "jdoe"
},
"events": {
"urn:ietf:params:event:SCIM:prov:create": {
"attributes": [
"id",
"name",
"userName",
"password",
"emails"
]
}
}
}
Figure 5: Example SCIM Create Event (CP Mode)
The event above notifies the Event Receiver which attributes have
changed but does not convey the actual information. The Event
Receiver MAY retrieve that information by performing a SCIM GET to
the sub value specified.
2.4.2. urn:ietf:params:event:SCIM:prov:patch
The specified resource has been updated using SCIM PATCH. When in
DBR mode, the data attribute contains the PATCH Request body. In CP
mode, only the modified attribute name is included.
Hunt & Cam-Winget Expires 24 July 2023 [Page 11]
Internet-Draft draft-ietf-scim-events January 2023
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2",
"externalId": "crmUsers"
},
"events":{
"urn:ietf:params:event:SCIM:prov:patch": {
"version": "a330bc54f0671c9",
"data": {
"schemas":
["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":[{
"op":"add",
"path":"members",
"value":[{
"display": "Babs Jensen",
"$ref": "/Users/2819c223...413861904646",
"value": "2819c223-7f76-453a-919d-413861904646"
}]
}]
}
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 6: Example SCIM Patch Event (DBR Mode)
Hunt & Cam-Winget Expires 24 July 2023 [Page 12]
Internet-Draft draft-ietf-scim-events January 2023
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Groups/176f397ec4c44b94b2cfcb759780b8c2",
"externalId": "crmUsers"
},
"events":{
"urn:ietf:params:event:SCIM:prov:patch": {
"attributes": ["members"],
"version": "a330bc54f0671c9"
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 7: Example SCIM Patch Event (CP Mode)
2.4.3. urn:ietf:params:event:SCIM:prov:put
The specified resource has been updated (e.g. one or more attributes
has changed). In DBR mode, the SCIM PUT request body is included in
the data attribute; or, In CP mode the modified attributes are listed
using attributes.
Hunt & Cam-Winget Expires 24 July 2023 [Page 13]
Internet-Draft draft-ietf-scim-events January 2023
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646"
},
"events":{
"urn:ietf:params:event:SCIM:prov:put": {
"version": "a330bc54f0671c9",
"data": {
"schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName":"jdoe",
"externalId":"jdoe",
"name":{
"formatted":"Mr. Jon Jack Doe III",
"familyName":"Doe",
"givenName":"Jon",
"middleName":"Jack"
},
"roles":[],
"emails":[
{"value":"jdoe@example.com"},
{"value":"anon@jdoe.org"}
]
}
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 8: Example SCIM Put Event (DBR Mode)
Hunt & Cam-Winget Expires 24 July 2023 [Page 14]
Internet-Draft draft-ietf-scim-events January 2023
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2819c223-7f76-453a-919d-413861904646"
},
"events":{
"urn:ietf:params:event:SCIM:prov:put": {
"version": "a330bc54f0671c9",
"attributes": ["userName","externalId","name","roles","emails"]
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 9: Example SCIM Put Event (CP Mode)
2.4.4. urn:ietf:params:event:SCIM:prov:delete
The specified resource has been deleted from the SCIM publisher. The
resource is also removed from the feed. When a DELETE is sent, a
corresponding feedRemove is not issued. A delete event has minimal
disclosure profile only.
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462",
"externalId": "jDoe"
},
"events":{
"urn:ietf:params:event:SCIM:prov:delete": {}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 10: Example SCIM Delete Event
Hunt & Cam-Winget Expires 24 July 2023 [Page 15]
Internet-Draft draft-ietf-scim-events January 2023
2.4.5. urn:ietf:params:event:SCIM:prov:activate
The specified resource (e.g. User) has been activated. This event
indicates a high-level change in state as agreed between the Event
Publisher and Event Receiver. For example, an activated resource is
one that can now have an active session (may log in) from a security
perspective.
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/2b2f880af6674ac284bae9381673d462"
},
"events":{
"urn:ietf:params:event:SCIM:prov:activate": {}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 11: Example SCIM Activate Event
2.4.6. urn:ietf:params:event:SCIM:prov:deactivate
The specified resource (e.g. User) has been deactivated and
disabled. The exact meaning must be agreed to by the Event Publisher
and its corresponding Event Receiver. Typically this means the sub
may no longer have an active security session. As with the activate
event, this event has minimal disclosure requirements.
2.5. SCIM Signals Events
This section defines security signal events that have occured within
a SCIM Service Provider.The URI prefix for these events is:
urn:ietf:params:event:SCIM:signal
2.5.1. urn:ietf:params:event:SCIM:sig:authMethod
A new authentication method has been added to the User profile. As
attackers often use new authentication methods to lock-out Users from
their account, this signal can be used by the receiver that the
chance of account them may be temporarily elevated. The receiver MAY
also wish to take action such as resetting current authorizations or
sessions.
Hunt & Cam-Winget Expires 24 July 2023 [Page 16]
Internet-Draft draft-ietf-scim-events January 2023
{
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
"sub_id": {
"format": "scim",
"uri": "/Users/44f6142df96bd6ab61e7521d9"
},
"events":{
"urn:ietf:params:event:SCIM:sig:authMethod": {}
},
"iat": 1458496025,
"iss": "https://scim.example.com"
}
Figure 12: Example SCIM Authentication Factor Change Event
2.5.2. urn:ietf:params:event:SCIM:sig:pwdReset
The specified resource (e.g. User) has changed its password or the
password has been reset. When the password has changed, the
attributes attribute is supplied with the value "password".
{
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
"sub_id": {
"format": "scim",
"uri": "/Users/44f6142df96bd6ab61e7521d9"
},
"events": {
"urn:ietf:params:event:SCIM:sig:pwdReset": {}
},
"iat": 1458496025,
"iss": "https://scim.example.com",
"aud":[
"https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
]
}
Figure 13: Example SCIM Password Change Event
2.6. Miscellaneous Events
This section defines events related miscellaneous events such as
Asynchronous Request complettion that have occured within a SCIM
Service Provider. The URI prefix for these events is:
urn:ietf:params:event:SCIM:misc
Hunt & Cam-Winget Expires 24 July 2023 [Page 17]
Internet-Draft draft-ietf-scim-events January 2023
2.6.1. urn:ietf:params:event:SCIM:misc:asyncResp
This event signals the completion of a SCIM request. The payload
contains the attributes defined in SCIM Bulk Section 3.7 [RFC7644]
and is the same a single SCIM Bulk Response Operation as per
Section 3.7.3.
{
"jti": "6164f3bbf6ff41a88dc94f18cb0620e8",
"sub_id": {
"format": "scim",
"uri": "/Users/b7c14771-226c-4d05-8860-134711653041"
},
"txn": "7880fc68a2f0428ebbb5a906e5aeae53",
"events":{
"urn:ietf:params:event:SCIM:misc:asyncResp": {
"method": "PUT",
"version": "W\/\"huJj29dMNgu3WXPD\"",
"status": "200"
}
},
"iat": 1458505044,
"iss":"https://scim.example.com",
"aud":[
"https://scim.example.com/Feeds/98d52461fa5bbc879593b7754"
]
}
Figure 14: Example SCIM Async Response Event
3. Event Delivery
For the purposes of SCIM, this draft uses the following methods
exchange of events using the Security Event Token exchange methods:
[RFC8935]
Push-Based Security Event Token (SET) Delivery delivers tokens to
an Event Receiver with an accessible HTTP Entpoint.
[RFC8936]
Poll-Based Security Event Token (SET) Delivery enables an event
receiver to initiate calls to SET Event publisher endpoint to
receive 1 or more events. This is particularly advantageous when
an Event Receiver is behind a firewall or other network
restriction that would prevent Push Delivery. An Event Receiver
may also use HTTP "Long-polling" to achieve real time event
delivery.
Hunt & Cam-Winget Expires 24 July 2023 [Page 18]
Internet-Draft draft-ietf-scim-events January 2023
In the figure below, a possible distribution architecture is shown.
This specification is only normatively concerned with the actual
Security Event Transfer mechanism. SCIM Service providers MAY choose
to implement SET transfer directly or they may use a method of
allowing a single Event Publisher to assemble streams of events for
transfer to a receiver. Likewise, on the receiving side, the only
normative requirement is to be able to receive events and implement
storage of Events to local recovery needs.
┌───────────────┠┌───────────────┠┌───────────────â”
│ │ │ │ │ │
│ SCIM Server 1 │ │ SCIM Server 2 │ ... │ SCIM Server n │
│ │ │ │ │ │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
┌───────▼──────────────────▼─────────────────────▼───────â”
│ Local Event Delivery System │
└───────────────────────────┬────────────────────▲───────┘
│ │
┌────────▼────────┠┌──────┴───────â”
│ │ │ Recovery │
│ Event Publisher ◄────► Buffer │
│ │ └──────────────┘
└────────┬────────┘
┌── │
│ ┌────────▼────────â”
│ │ SET Trans Txmtr │
│ │ (RFC 8935/8936) │
Minimum │ └────────┬────────┘
Interop │ │
Requirement│ │
│ ┌────────▼────────┠┌──────────────â”
│ │ SET Trans Rcvr │ │ Event │
│ │ (RFC 8935/8936) ├────► Storage │
│ └────────┬────────┘ └──────────────┘
└── │
┌────────▼────────â”
│ Receiver Domain │
│ Event Processor │
└────────┬────────┘
│
â–¼
Figure 15
As Security Event Tokens are based on JWT tokens, it is possible to
exchange events by a number of transfer mechanisms such as: XMPP
[RFC6120], HTTP [RFC7540], and Message Buses (e.g. [RFC3259], Apache
Hunt & Cam-Winget Expires 24 July 2023 [Page 19]
Internet-Draft draft-ietf-scim-events January 2023
Kafka [Kafka]). For example, on the publishing side, a cluster or
network of SCIM servers may publish events to a common SET publisher
service for distribution to 1 or more receivers. The Event Publisher
MAY be incorporated directly into each SCIM Server, or a Local Event
Delivery System might be used to collect events for an Event
Publisher service for forwarding. How this is done is up to the
implementer. This specification is only concerned with the
interoperability of SET transfer between domains using [RFC8935] and
[RFC8936].
The SET Transfer specifications provide a short-term method of
recovery to ensure SET Events are successfully transferred. Once a
receiving domain has successfully stored events to its own recovery
needs, the receiving domain acknowledges the transfer of SET Events
to the publisher using the method defined in [RFC8935] and [RFC8936].
SET does not specify local server event recovery mechanisms, this is
up to the service implementation within each domain. This is done to
enable cross-domain independence between domains. As an example, a
hosted SCIM service provider with a series of SCIM servers replicates
through a proprietary system. An enterprise customer who is the
common client across both providers wants to establish a single
administrative domain and wants to share SCIM change events between
providers. Each domain has its own SCIM implementation and its own
local replication strategy. The publishing domain issues events that
the receiving domain picks up. Once the receiving domain has
processed the event, the receiving domains own internal replication
and recovery takes over. Because there is no need for the publishing
domain to retain the event, it has the option to purge the event once
the receiving domain has acknowledged it. This may be particularly
critical if a publishing domain has dozens or even thousands of event
receiving domains each with their own sub-set of data. Retaining all
events for all receivers would become impracticle.
3.1. Security Event Token Signing and Encryption
This specification uses Security Event Tokens as the message format
for SCIM Events. As SETs are based on JWT tokens [RFC7519], they can
be transmitted unsecurity, signed, or encrypted. For more
information see the JWT Cookbook specification [RFC7520] for
examples. The decision on whether to use JWS and JWE depends on
operational considerations. For each SCIM Feed relationship, it is
up to deployers to decide on signing, encryption and algorithm
requirements. Deployers SHOULD be aware that too much emphasis on
turning on every possible encryption feature may cause operational
performance to suffer. Deployers MUST weigh the security trade-offs
of up-to-date SCIM services, vs. the potential information loss of an
event.
Hunt & Cam-Winget Expires 24 July 2023 [Page 20]
Internet-Draft draft-ietf-scim-events January 2023
Unsecured
Per Section 6 [RFC7519], tokens MAY be generated with
{"alg":"none"}. This mode speeds up processing and is best used
in DBR scenarios. Unencrypted tokens MUST be transferred over
authenticated TLS layer encryption and SHOULD only be used in a
restricted network environment.
Signed
JWS ([RFC7515]) signed SETs are useful when it is important to be
able to verify the issuer of a SET as valid. In addition, some
systems MAY wish to validate the authenticity of the event in a
review process which may occur at a later date. While the content
can be validated as originating from the correct issuer and is
unmodified, the message contents remain unsecure. Signed SETs
MUST be transferred over encrypted transport.
Encrypted
JWE ([RFC7516]) are encrypted SETs and are useful when the
transport mechanism is not fully securable (e.g. messages carried
by a third party). The use of JWEs ensures only the designated
receiver can read the event and provides mutual authentication
within the SET mesage itself.
3.2. Point-to-Point Delivery Over HTTP
Security Event Tokens MAY be delivered using push-based HTTP delivery
[RFC8935], or pull-based HTTP Polling [RFC8936]. Both of these
protocols define a method of transfer and acknowledgement to prevent
loss-of-information and to provide re-transmission and recover. The
method of transfer is best decided by considering the following
advantages and disadvantages in a production scenario:
Push-based delivery has the following advantages:
* Message transfer is instant (when compared to using a common Event
Publisher acting as a relay), and in high event frequency
scenarios, HTTP connections can be kept open.
* Scales well when an SCIM Event Publisher has thousands of event
receivers and TCP resources may be limited.
* Does not require events to be routed to a single publisher node.
SCIM Events may be issued by SCIM Service Provider nodes where the
transaction occurred.
* SCIM Events only need to be retained until they have been
delivered to designated receivers.
Hunt & Cam-Winget Expires 24 July 2023 [Page 21]
Internet-Draft draft-ietf-scim-events January 2023
Push-delivery has the following disadvantages:
* A SCIM Event Publisher system needs authorization credentials
enabling it to access the HTTP SCIM Event delivery endpoint.
* When synchronizing business data that is behind protected
firewalls, a virtual network or other firewall policy may be
required to allow external network based SCIM providers to deliver
SCIM Events to internally hosted systems.
Delivery by HTTP Polling has the following advantages:
* It is possible for a SCIM Event Receiver to use the same SCIM
credentials it uses when access the normal SCIM Service Provider
service defined by [RFC7644].
* Systems behind protected network boundaries can reach externally
hosted systems without requiring special firewall or network
configuration.
* Instantaneous transfer can be used using HTTP Long-polling as
described Section 2.1 of [RFC8936].
Polling-based delivery has the following disadvantages:
* Long-polling requires the use of persistent connections for which
TCP resources may be limited. HTTP Long-polling is best used in
scenarios when there are relatively few Event Receivers.
* The SCIM Event Publisher MUST retain events for the Event Receiver
until delivered.
4. Security Considerations
This specification depends on the Security Considerations for
[RFC8417].
The use of Json Web Encryption (JWE) [RFC7516] can impose performance
limitations when used in high event frequency scenarios. JWE is
primarily useful only when the transfer of SETs involves an unsecured
transfer method (e.g. URL) that would not otherwise be protected by
the transfer protocol (e.g. SET Transfer over TLS [RFC5246]).
Hunt & Cam-Winget Expires 24 July 2023 [Page 22]
Internet-Draft draft-ietf-scim-events January 2023
For SCIM Provisioning events, the long-term series of changes may be
critical to both sides. As such Event Publishers SHOULD consider
storing events for receivers for longer periods of time in the case
of an extended SET Transfer service failure. Similarly Event
Receivers MUST ensure events are persisted directly or indirectly
sufficient to meet local recovery needs before acknowledging received
SET Events.
When SET Events are stored for future delivery or retained local
recovery MUST be limited only to the parties needed to support
recovery or SET forwarding.
JWS [RFC7515] signed SET Events SHOULD be used to verify authenticity
of the origin of a SET Event. Validating event signatures is both
useful on the initial transfer of SET Events, and may also be useful
for auditing purposes.
In operation, some SCIM resources such as SCIM Groups may have a high
rate of change. Implementors and operators SHOULD consider use of
throttling techniques to balance immediacy and frequency. For
example, a large group whose members change dozens of times per
second may not need discrete SET Patch Events per change. Instead,
issuing a single consolidated change per second or even minute may be
beneficial to keeping Event Receivers up-to-date. Likewise, a Co-
ordinated Provisioning Event Receiver (Section 2.2), does not
necessarily need to retrieve the full Group on every change request.
It MAY choose to do lookups on a less frequent scale for
reconciliation.
5. Privacy Considerations
This specification enables the sharing of information between
domains. The specification assumes that implementers and deployers
are operating under one of the following scenarios:
* A common administrative domain where there is one administrative
owner of the data. In these cases the objective is to protect
privacy and security of the owner and user data by keeping
information systems co-ordinated and up-to-date. For example, the
domains decide to use Domain Based Replication mode in order to
keep employee information synchronized.
* In a co-operative or co-ordinated relationship, parties have
decided to share a limited amount of data and or signals for the
benefits of their users. Depending on end-user consent,
information is shared on an as authorized and/or as needed basis.
For example, the domains agree to use Co-ordinated Provision mode
that exchanges things like account status, or specific minimal
Hunt & Cam-Winget Expires 24 July 2023 [Page 23]
Internet-Draft draft-ietf-scim-events January 2023
attribute information needed that must be fetched on request after
receiving notice of a change. This enables authorization to be
verified each time data is transferred.
In general the sharing of SCIM Event information falls within a pre-
existing SCIM Client and Service Provider relationship. In the case
of SCIM Risk Signals Events, the existing relationship may need to be
reviewed. By their nature, however, SCIM Signals carry no personal
information and aid parties in ensuring the protection of privacy
information and account security.
Privacy considerations of [RFC8417] MUST also be observed.
6. IANA Considerations
This section registers the schema extensions found in Section 2 in
the "Event" registry as per Section 4.2 [RFC8417].
Schema URI: SeeSection 2.
Schema Name: See corresponding names underSection 2.
Intented ResourceType: N/A. Events are not intended to be persisted
in SCIM.
Purpose: See each description inSection 2.
Single-valued Attributes: None.
Multi-valued Attributes: All schemas in this specification share the
same attributes. SeeSection 2.2.
Summary of schema URI registrations:
+==========================================+==============+=========+
|Schema URI |Name |Reference|
+==========================================+==============+=========+
|urn:ietf:params:event:SCIM:feed:add |Resource added|Section |
| |to Feed Event |2.3.1 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:feed:remove |Remove resouce|Section |
| |From Feed |2.3.2 |
| |Event | |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:prov:create |New Resource |Section |
| |Event |2.4.1 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:prov:patch |Resource Patch|Section |
Hunt & Cam-Winget Expires 24 July 2023 [Page 24]
Internet-Draft draft-ietf-scim-events January 2023
| |Event |2.4.2 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:prov:put |Resource Put |Section |
| |Event |2.4.3 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:prov:delete |Resource |Section |
| |Deleted Event |2.4.4 |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:prov:activate |Resource |Section |
| |Activated |2.4.5 |
| |Event | |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:prov:deactivate|Resource |Section |
| |Deactivated |2.4.6 |
| |Event | |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:sig:authMethod |New |Section |
| |authentication|2.5.1 |
| |method added | |
+------------------------------------------+--------------+---------+
|urn:ietf:params:event:SCIM:sig:pwdReset |Password Reset|Section |
| |Event |2.5.2 |
+------------------------------------------+--------------+---------+
Table 1
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240,
DOI 10.17487/RFC7240, June 2014,
<https://www.rfc-editor.org/info/rfc7240>.
Hunt & Cam-Winget Expires 24 July 2023 [Page 25]
Internet-Draft draft-ietf-scim-events January 2023
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7520] Miller, M., "Examples of Protecting Content Using JSON
Object Signing and Encryption (JOSE)", RFC 7520,
DOI 10.17487/RFC7520, May 2015,
<https://www.rfc-editor.org/info/rfc7520>.
[RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C.
Mortimore, "System for Cross-domain Identity Management:
Core Schema", RFC 7643, DOI 10.17487/RFC7643, September
2015, <https://www.rfc-editor.org/info/rfc7643>.
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
and C. Mortimore, "System for Cross-domain Identity
Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
September 2015, <https://www.rfc-editor.org/info/rfc7644>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
"Security Event Token (SET)", RFC 8417,
DOI 10.17487/RFC8417, July 2018,
<https://www.rfc-editor.org/info/rfc8417>.
[SSWG] Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman,
A., and J. Bradley, "OpenID Shared Signals and Events
Framework Specification 1.0 - draft 01", 8 June 2021.
Cappalli, T. and A. Tulshibagwale, "OpenID Continuous
Access Evaluation Profile 1.0 - draft 02", 8 June 2021.
[SUBID] Ed, A. B., Scurtescu, M., and P. Jain, "Subject
Identifiers for Security Event Tokens (Draft 14)", 27
October 2022.
7.2. Informative References
Hunt & Cam-Winget Expires 24 July 2023 [Page 26]
Internet-Draft draft-ietf-scim-events January 2023
[Kafka] Apache Software Foundation, "Apache Kafka", 2017.
[RFC3259] Ott, J., Perkins, C., and D. Kutscher, "A Message Bus for
Local Coordination", RFC 3259, DOI 10.17487/RFC3259, April
2002, <https://www.rfc-editor.org/info/rfc3259>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC8935] Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari,
M., and A. Nadalin, "Push-Based Security Event Token (SET)
Delivery Using HTTP", RFC 8935, DOI 10.17487/RFC8935,
November 2020, <https://www.rfc-editor.org/info/rfc8935>.
[RFC8936] Backman, A., Ed., Jones, M., Ed., Scurtescu, M., Ansari,
M., and A. Nadalin, "Poll-Based Security Event Token (SET)
Delivery Using HTTP", RFC 8936, DOI 10.17487/RFC8936,
November 2020, <https://www.rfc-editor.org/info/rfc8936>.
Appendix A. Use Cases
SCIM Events may be used in a number of ways. The following non-
normative sections describe some of the expected uses.
A.1. Domain Based Replication
The objective of "Domain Based Replication" events (DBR) is to
synchronize resource changes between SCIM service providers in a
common administrative domain. In this mode, complete information
about changes for resources are shared between replicas for immediate
processing.
Hunt & Cam-Winget Expires 24 July 2023 [Page 27]
Internet-Draft draft-ietf-scim-events January 2023
┌────────────────â”
┌────────┠│SCIM │ ┌────────────────────────â”
│Client A│ │Service Provider│ │Service Provider Replica│
└───┬────┘ └───────┬────────┘ └───────────┬────────────┘
│ "SCIM Operation" ┌┴┠│
│ ────────────────────>│ │ │
│ │ │ │
│ "SCIM Response" │ │ ┌┴â”
│ <────────────────────│ │ │ │
│ └┬┘ │ │
│ │ "Event SCIM:prov:<op>│ │
│ │ id:xyz" │ │
│ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─>│ │
│ │ │ │
│ │ │ │
│ │ │ │────â”
"Update local node"│ │ │
│ │<───┘
└┬┘
Figure 16: Domain Based Replication Sequence
From a security perspective, it is assumed that servers sharing DBR
events are secured by a common access policy and all servers are
required to be up-to-date. From a Privacy Perspective, because all
servers are in the same administrative domain, the primary objective
is to keep individual service provider nodes or cluster synchronized.
A.2. Co-ordinated Provisioning
In "Co-ordinated Provisioning" (CP), SCIM resource change events
perform the function of change notification without the need to
provide raw data. In any Event Publisher and Receiver relationship,
the set of SCIM resources (e.g. Users) that are linked or co-
ordinated is managed within the context of a an event feed and which
MAY be a subset of the total set of resources on either side. For
example, an event feed could be limited to users who have consented
to the sharing of information between domains. To support
capability, "feed" specific events are defined to indicate the
addition and removal of SCIM resources from a feed. For example,
when a user consents to the sharing of information between domains,
events about the User MAY be added to the feed between the Event
Publisher and Receiver.
Hunt & Cam-Winget Expires 24 July 2023 [Page 28]
Internet-Draft draft-ietf-scim-events January 2023
┌────────────────┠┌──────────────┠┌─────────────â”
┌───────────┠│SCIM │ │Client A │ │Co-op Action │
│SCIM Client│ │Service Provider│ │Co-op Receiver│ │Endpoint │
└─────┬─────┘ └───────┬────────┘ └──────┬───────┘ └───────┬─────┘
│ "SCIM Ope" ┌┴┠│ │
│──────────────>│ │ │ │
│ │ │ │ │
│ "SCIM Resp" │ │ ┌┴┠│
│<──────────────│ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ â•”â•â•â•â•â•â•â•â•¤â•ªâ•â•ªâ•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•ªâ•â•ªâ•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•ªâ•â•â•â•â•—
│ ║ LOOP ││ │ │ │ │ ║
│ ╟───────┘└┬┘ Event: │ │ │ ║
│ ║ │ SCIM:prov:<op>│ │ │ ║
│ ║ │ id:xyz │ │ │ ║
│ ║ │ ─ ─ ─ ─ ─ ─ ─ >│ │ │ ║
│ ║ │ │ │ │ ║
│ â•‘ │ â•”â•â•â•â•â•â•â•â•â•â•â•â•â•§â•â•§â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•— │ â•‘
│ ║ │ ║Receiver may accumulate ║ │ ║
│ ║ │ ║events for periodic action. ║ │ ║
│ â•‘ │ â•šâ•â•â•â•â•â•â•â•â•â•â•â•â•¤â•â•¤â•â•â•â•â•â•â•â•â•â•â•â•â•â•â• │ â•‘
│ ║ │ SCIM GET <id> │ │ │ ║
│ ║ │ <───────────────│ │ │ ║
│ ║ │ │ │ │ ║
│ ║ │ Filtered │ │ │ ║
│ ║ │ Resource Resp │ │ │ ║
│ ║ │ ───────────────>│ │ │ ║
│ ║ │ │ │ │ ║
│ ║ │ │ │ "Co-ord Action" │ ║
│ ║ │ │ │ ───────────────>│ ║
│ â•šâ•â•â•â•â•â•â•â•â•â•ªâ•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•ªâ•â•ªâ•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•â•ªâ•â•â•â•â•
Figure 17: Co-Ordinated Provisioning Sequence
In CP mode, the receiver of an event must call back to the
originating SCIM Service Provider (e.g. using a SCIM GET request) to
reconcile the newly changed resource in order to obtain the changes.
Co-ordinated provisioning has the following benefits:
* Differences in schema (e.g. attributes) between domains. For
example, a receiving domain may only be interested or only be
allowed access to a few attributes (e.g. role based access data)
to enable access to an application.
Hunt & Cam-Winget Expires 24 July 2023 [Page 29]
Internet-Draft draft-ietf-scim-events January 2023
* Different Event Receivers MAY have differing needs access to
information and thus be assigned varying access rights. Minimal
information events combined with call-backs for data allows data
filtering to be applied.
* Receivers can take independent action. For example deciding which
attributes or resource lifecycle changes to accept. For example,
in the case of a conflict, a receiver can prioritize one domain
source over another.
* A receiver MAY throttle or buffer changes rather than act
immediately on a notification. For example, for a frequently
changing resource, the receiver MAY choose to make scheduled SCIM
GET for resources that have been marked "dirty" by events received
in the last scheduled cycle.
A disadvantage of the CP approach is that it may be considered costly
in the sense that each event received might trigger a call back to
the event issuer. This cost should be weighed against the cost
producing filtered information in each event for each receiver.
Further a receiver is not required to make a call-back on every
provisioning event.
It is assumed that an underlying relationship between domains exists
that permits the exchange of personal information and credentials.
For example the decision to perform SCIM provisioning operations at
the SCIM Service Provider issuing change events, was previously
authorized and appropriate confidentiality and privacy agreements
have been met in cross-domain scenarios. Examples of this might be
services for hire by an employer or a specific consent from an end-
user as part of a online authorization where individual consent was
obtained.
When sharing information between parties, CP Events minimize the
information shared in each message requiring the Security Event
Receiver to call back to the event publisher to retrieve more
information if required. In this way, the Event Publisher is able to
regular access to information through normal SCIM protocol access
restrictions.
A.3. Risk Signals
The sharing of risk signals (RS) is used for the purpose of co-
ordinating account change events between a SCIM Service Provider and
another related security service. For example, when a password or
other authentication factor has changed, a receiving security system
can choose to terminate current User sessions to force a re-
authentication against the modified User resource.
Hunt & Cam-Winget Expires 24 July 2023 [Page 30]
Internet-Draft draft-ietf-scim-events January 2023
These signals MAY also include those described in the OpenID Shared
Signals Working Group Specifications [SSWG].
These events are intended for receivers where there is a prior
relationship on behalf of the users described in the SCIM Service
Provider. The intent of sharing information about security events is
for the purpose of securing a user account and ensuring privacy.
A.4. Async Requests
A SCIM provisioning client MAY wish to request "asynchronous"
processing using the "Prefer Header for HTTP", Section 4.1 [RFC7240].
In this mode, a normal SCIM protocol POST, PUT, PATCH, or DELETE
request is made, and the HTTP Header Prefer is included with the
value respond-async. When a SCIM Client signals respond-async, the
SCIM server response changes to HTTP Status 202 Accepted as defined
in [RFC7231]. The Location header returned is the final resource
location and no payload is present. Following acceptance of an
asynchronous request, a notification of completion can be issued
using the Async Event Notification per Section 2.6.1. The location
returned SHALL correspond to the sub claim in the future Async Event
SET message.
{
┌──────────────┠┌────────────────â”
┌────────┠│Client A │ │SCIM │
│Client A│ │Event Receiver│ │Service Provider│
└───┬────┘ └──────┬───────┘ └───────┬────────┘
│ "SCIM Modify ┌┴â”
│ w/Respond Async" │ │
│ ──────────────────────────────────────────────────>│ │
│ │ │ │
│ "Accepted Status 202" │ │
│ "Location: /Users/xyz" │ │
│ <──────────────────────────────────────────────────│ │
│ │ │ └┬┘
│ │ │ "Event SCIM:misc:asyncResp │
│ │ │ sub: /Users/xyz │
│ │ │ id:xyz, method: PUT" │
│ │ │ <─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─│
│ └┬┘ │
│ "ID: xyz created" │ │
│ <─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
Figure 18: Asychronous Request Sequence
Hunt & Cam-Winget Expires 24 July 2023 [Page 31]
Internet-Draft draft-ietf-scim-events January 2023
Appendix B. Acknowledgments
Thanks to Morteza Ansari who contributed significantly to draft-hunt-
idevent-scim-00, upon which this draft is based.
The editor would like to thank the participants in the SCIM working
group and the id-event list for their support of this specification.
Appendix C. Change Log
Draft 00 - PH - First Draft
Authors' Addresses
Phil Hunt (editor)
Independent Identity Inc
Email: phil.hunt@independentid.com
Nancy Cam-Winget
Cisco Systems
Email: ncamwing@cisco.com
Hunt & Cam-Winget Expires 24 July 2023 [Page 32]