Network Working Group P. Hunt, Ed.
Internet-Draft Oracle
Intended status: Standards Track M. Ansari
Expires: January 1, 2018 Cisco
June 30, 2017
SCIM Use Cases for SECEVENTS
draft-hunt-secevent-usecases-00
Abstract
This specification defines the SCIM use cases for the SECEVENTs
working group.
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 http://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 January 1, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hunt & Ansari Expires January 1, 2018 [Page 1]
Internet-Draft draft-hunt-secevent-usecases June 2017
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. SCIM Background . . . . . . . . . . . . . . . . . . . . . . . 3
3. High-Level Requirements . . . . . . . . . . . . . . . . . . . 5
3.1. SCIM Event Trigger Requirements . . . . . . . . . . . . . 5
3.2. SCIM Security Model Considerations . . . . . . . . . . . 5
3.3. Control Plane Assumptions . . . . . . . . . . . . . . . . 6
3.4. Network and Protocol Operational Considerations . . . . . 8
3.5. Dynamic Filtering Considerations . . . . . . . . . . . . 8
3.6. Directory and Application Provisioning . . . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Scenario 1[P0]: Cloud-to-Enterprise PUSH and Cloud-to-
Cloud PUSH . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Scenario 2[P0]: Cloud-to-Enterprise POLLING . . . . . . . 12
4.3. Scenario 3[P2]: Cloud-to-Mobile Application PUSH . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction and Overview
SCIM is a system intended for provisioning identities (such as
enterprise users or consumers) and other objects across security
domains to a cloud based service providers. SCIM defines an
extensible JSON [RFC7643] document format and profiles HTTP protocol
[RFC7644]. In practice, SCIM service providers are applications
supporting pre-provisioning support, or may be a service provider
directory upon which applications are integrated.
This document defines the operational requirements SCIM deployers
have for the use of triggers, as defined in the SCIM Use Cases
specification [RFC7642], and used in the form of security events and
the requirements for management based on SCIM architectural
assumptions.
Hunt & Ansari Expires January 1, 2018 [Page 2]
Internet-Draft draft-hunt-secevent-usecases June 2017
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] . These
keywords are capitalized when used to unambiguously specify
requirements of the protocol or application features and behavior
that affect the inter-operability and security of implementations.
When these words are not capitalized, they are meant in their
natural-language sense.
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.
1.2. Definitions
This specification assumes terminology defined in the Security Event
Token specification[I-D.ietf-secevent-token] .
This specification assumes terminology defined in the SCIM
specifications, specifically [RFC7643] and [RFC7644]
This specification defines the following terms:
Directory
Defined as any centralized repository of security objects shared
by multiple applications. A SCIM Directory, though not formally
defined is simply a directory that supports SCIM protocol.
2. SCIM Background
The SCIM Core Schema specification [RFC7643] is a profile of JSON
[RFC7159] that defines attribute types, mutability, data formats,
composites, and multi-value attributes as well as SCIM Service
Provider feature and schema discovery metadata. As core schema
defines standard resource types: Users and Groups which are common to
most service providers. Each resource type establishes a common set
of attribute definitions that can be mapped to SAML [saml-core-2.0]
and to OpenID Connect [openid-connect-core] as well as application
specific attributes. The core schema specification provides an
extension mechanism which has been popular in:
Hunt & Ansari Expires January 1, 2018 [Page 3]
Internet-Draft draft-hunt-secevent-usecases June 2017
o Being extended to describe many security objects such as OAuth
Clients, Applications, IoT objects, among others.
o Enabling localized extensions to standard resource types (e.g.
Users) without compromising inter-operability of existing
implementations.
The SCIM Protocol specification [RFC7644] describes a RESTful profile
of HTTP [RFC7231] that defines create, read, update and delete life-
cycle for resources. The processing rules follow Jon Postel's
"Robustness Principle" (see Section 2.10 [RFC761]) which help avoid
many of the failings of previous XML based approaches. In particular
the use of robust RESTful JSON helped ensure client and server
ability to deal with inter-domain differences in schema, data, and
implementation avoiding a lot of per implementation/deployment custom
connector approaches.
SCIM clients use HTTP requests to SCIM service providers as follows
to:
o Query for resources (users and groups) based on filters using HTTP
GET or confidentially using HTTP POST.
o Retrieve specific resources using HTTP GET.
o Create new resources using HTTP POST.
o Replace a resource using HTTP PUT.
o Update a resource using HTTP PATCH. And,
o Delete a resource using HTTP DELETE.
The SCIM Protocol defines capabilities for:
o Complex or composite attributes that contain multiple values and
the need to select and update specific values. This includes how
to express sub-attributes and values in filters and the ability to
change them as part of a resource. An example of a composite
attribute in SCIM is: addresses (e.g. street name, city, country).
Note: In SECEVENTs a corresponding example complex/composite
attribute is an OpenID Connect user which is identified by both
'sub' and 'iss'.
o How to handle attributes that are immutable or read-only in the
context of operations like PUT. How to handle attributes that are
hashed or write-only and cannot be retrieved.
Hunt & Ansari Expires January 1, 2018 [Page 4]
Internet-Draft draft-hunt-secevent-usecases June 2017
o Flexibility for web applications to take what they want without
having traditional schema enforcement as with XML Schema.
o How to handle identifiers between clients and service providers
and across domains.
o Referential stability of resources over time.
Some other relevant information:
o SCIM Polling Draft form Craig McMurtry [I-D.mcmurtry-scim-polling]
o Early SCIM Events proposal [I-D.hunt-idevent-scim]
3. High-Level Requirements
3.1. SCIM Event Trigger Requirements
SCIM's need for Security Events arises from a requirement for
triggers identified in the SCIM Use Case specification [RFC7642].
Clients and service providers that operate across security domains
have independent resource management that causes co-ordination and
governance challenges between domains. The use of triggers is
intended to alert clients (e.g. enterprises) of state changes within
service providers that may be of interest to SCIM clients that may
need to be co-ordinated or reconciled across domains.
As a general example, a change to a resource that occurs within a
cloud software as a service (SaaS) provider generates an Event to be
sent to a registered recipient via an Event Stream. Upon receipt of
the event, the receiver performs a SCIM GET to obtain additional
information and then decide if a local update or other action is
required.
3.2. SCIM Security Model Considerations
Authentication and Authorization
SCIM follows normal authentication and authorization practices for
HTTP (See Sections 2 and 7 [RFC7644]). In typical deployed cases,
access to SCIM endpoints is managed by OAuth authorization in both
cross-domain provisioning, delegated administration, and self-
service applications. Many integrators also support basic
authentication, and TLS mutual authentication. SCIM is often
accessed in a couple of ways:
* End-user servers (e.g. as facilitated via a /Me endpoint) via a
self-service web application or Javascript client.
Hunt & Ansari Expires January 1, 2018 [Page 5]
Internet-Draft draft-hunt-secevent-usecases June 2017
* Administrative - where an administrator identity has access to
groups of objects they are entitled to administer.
* Server-to-server, where identity provisioning systems
implementing management workflows initiate commands across
domains using OAuth enabled authorization.
PII Confidentiality
Querying using personally identifiable information (PII) causes
privacy concerns when using HTTP GET. In typical HTTP usage,
since HTTP [RFC7231] does not allow for query payloads on an HTTP
GET, query parameters and filters are typically passed as part of
the URL. When queries contain PII (most will in the case of
RISC), there are security issues (e.g. leakage via audit logs and
browser histories) relating to passing filter terms that contain
PII in URLs. See [RFC7642] Security Considerations, section
7.5.2. From the perspective of SECEVENTs, the SCIM community has
the same PII requirement that the management of SECEVENT streams
and delivery not pass PII in request URIs.
Scale, PII, and Multi-Valued Data
One of the concerns the SCIM working group had when developing
SCIM was the challenge that Groups (e.g. a group of users) will
tend to get very big at Internet scale. The bigger a Group gets,
the more expensive it is to enumerate. With a high change rate it
quickly become impractical to do a simple PUT to replace an entire
Group object due to the likely number of independent update
conflicts that would occur. To avoid this, implementers often:
* Severely restrict when clients are actually authorized to
return large objects (million member groups).
* Set access policy to allow search filters that confirm
membership but avoid returning the members attribute (to avoid
enumeration of all values).
* Use HTTP PATCH (a derivative of JSON Patch) to remove or add
specific subjects without having to know the entire contents
(e.g. the group).
3.3. Control Plane Assumptions
In the original SCIM identity event proposals, "Control Plane"
functionality was accomplished by SCIM. SCIM protocol was proposed
to configure and provision "streams" that deliver events via other
protocols or profiles. The SCIM proposal allowed Event Receivers to
check for delivery problems by retrieving Stream "resources" (which
contain the stream configuration attributes) of which "status" is an
Hunt & Ansari Expires January 1, 2018 [Page 6]
Internet-Draft draft-hunt-secevent-usecases June 2017
attribute that could be used to report operational state of a stream.
Updates to Stream resource enable Event Recipients to do things like
rotate credentials, or suspend streams. To initiate a verification
to test a stream is functional, the Receiver or an authorized
administrator can modify the Stream resource to "request" a verify by
changing the value of "status" to "verify". In SCIM the subjects in
a stream can be identified by a number of methods:
o Members of a Group
o The addition of a "streams" attribute to Users and other objects
that may be part of a stream.
o An attribute or filter condition. E.g. the members of a Stream
are defined by those Users with entitlements or roles containing a
specific value (e.g. "entitlements" eq "CRM").
The SCIM WG in re-using SCIM as the control plane had assumed the
following is already defined (and any alternative proposal would have
to support):
o Defined processing of attributes based on type, mutability, etc
for each HTTP method. For example, the handling of omitted
attributes in a PUT or POST operation. Is a value intended to be
defaulted or set to null?
o Handling of extensibility semantics as defined in the SCIM
specifications such as the definition of new resource types
(objects) and addition of new attributes by other profiling
specifications.
o The ability of a service provider to override or modify client
provider asserted values.
o Identifier and resource URI stability and referential integrity.
o Querying of subjects using various standard identifiers such as
"id", "emails", "telephoneNumbers", etc. The ability to express
composite queries such as "sub" and "iss" in a query.
o Ability to add and remove subjects from a group while keeping
enumeration of that group from the client. Ability to confirm
membership in a group without enumeration (facilitated through
support for write-only/compare-only schema or access control).
o Standardized error control, handling and processing rules. See
Section 3.12 [RFC7644] and [RFC7231].
Hunt & Ansari Expires January 1, 2018 [Page 7]
Internet-Draft draft-hunt-secevent-usecases June 2017
3.4. Network and Protocol Operational Considerations
The SCIM WG discussed that transmission (now called data-plane or
stream) can have much simpler semantics and error conditions and thus
did not need to profile JSON beyond simple SET transfer (no need for
attribute types, filters, etc). The SCIM WG also anticipated some
varied requirements for delivery that include:
o PUSH delivery via HTTP POST (the generally preferred ideal
solution).
o POLLING (to enable delivery across firewalls) using HTTP GET.
o PUSH delivery via messaging systems like APNS, GMS, SMS, etc -
many of these had to do with provisioning and entitlement signals
for mobile applications (e.g. WebEx). For example user contacts
synchronization where after a change to a user's contact list, an
application can receive an Event notification through the mobile
platform's messaging solution as a trigger to fetch changes.
3.5. Dynamic Filtering Considerations
When defining filtered Streams, SCIM has to consider some special
cases when the contents of a Stream is based upon a filter (query) to
define which affected resources are included. For example, if the
contents of a Stream is defined as Events related to resources where
"emails.value sw "A"" and a resource is deleted, then the deleted
resource won't match the filter anymore but notification may still
need to be sent.
3.6. Directory and Application Provisioning
Network relationships for connections are typically:
o Enterprise Directory to Cloud Directory.
o Cloud Directory to Cloud Directory.
o Enterprise or Cloud to Cloud Application (applications used by
many users).
o Enterprise or Cloud to Mobile Application (applications running on
a device controlled by a single user).
An enterprise directory is typically (but not always) legacy-LDAP.
In the cloud, a directory is simply any shared centralized profile
store (e.g. Google Dir, Azure Directory/OpenGraph, SCIM Directory,
etc). Important: While for many organizations LDAP remains the
Hunt & Ansari Expires January 1, 2018 [Page 8]
Internet-Draft draft-hunt-secevent-usecases June 2017
center of administrative control, it is important to note that cloud
directories and applications hold significantly more PII than
enterprise directories. This creates a challenge for enterprise
organizations to ensure proper governance and management of data
given that a lot of cloud data is independently managed and updated.
As with an enterprise directory, a cloud directory is often shared by
multiple applications. Cloud directories not only contain
entitlement information but now also contain CRM data, contact,
credentials, personalization and localization data, social network
data, etc (the list goes on). While some cloud providers centralize
others are tenancy structured with different directory endpoints per
tenancy (e.g. Oracle).
As described above, because data, particularly PII, is being
independently managed across multiple domains, there is a need to
generate change signals (events) from cloud based directories and
applications back to the enterprise. This was originally identified
in the SCIM Use Cases (see Section 2.2.1 [RFC7642]).
4. Use Cases
The following use cases are expressed in terms of the direction of
flow of events. In typical SCIM cases, there is only 1-way event
exchange. Typical usage of events is to act as a "trigger" (see
[RFC7642]) to let a receiver know that an event has occurred in the
transmitter's domain that may require action on the part of the
receiver. Events can be simple resource changed events, to higher
level account status and change events (e.g. account or password
reset). While many events are similar to OpenID RISC proposed
events, a major distinction is that SCIM events are often triggered
by user, administrative, or workflow provisioning action rather than
a risk analytical engine (e.g. that might detect suspicious
activity).
4.1. Scenario 1[P0]: Cloud-to-Enterprise PUSH and Cloud-to-Cloud PUSH
Pre-conditions:
The Event Receiver already has SCIM access to the Event
Transmitter service provider. This includes HTTP credentials and
endpoint.
Event Receivers and Transmitters can agree out-of-band on SET/JWT
security requirements including use of signing and/or encryption
to be documented in a Stream Configuration.
Hunt & Ansari Expires January 1, 2018 [Page 9]
Internet-Draft draft-hunt-secevent-usecases June 2017
+----------------+--------+
| SCIM | SCIM |
|Service Provider| Events |
| | Stream |
+--------^-------+--------+
SCIM| |Events via
Commands| |HTTP POST
| |
| |
| |
| |
+-+----------v-+
| SCIM Client |
| Provisioning |
| Controller |
+--------------+
Figure 1: SCIM Provisioining with PUSH Triggers
In Figure 1, the SCIM client initiates RESTful SCIM commands to a
SCIM service provider. In addition to provisioning security objects
such as Users and Groups, the client also uses SCIM to provision
Event Streams in order to receive Events to an endpoint the
provisioning controller requests. The service provider MUST be able
to POST to the client's domain. Usually this means the client is
able to have a public HTTP endpoint available to receive SET events.
Stream Creation Flow:
To create a Stream, the Event Receiver (or an administrator) uses
their SCIM access credential to access the SCIM endpoint and creates
a Stream resource configuration:
POST /Streams
Host: scim.bighost.com
Authorization: Bearer h480djs93hd8
{ "receiverId":"<client-id>",
"method":"webCallBack",
"receiverUri":"https://set.example.com/events/",
"aud":"<client-id>",
"type":"SCIM",
"receiverJwkUri":"<receiver's public key url>",
"authorization":"<btoken|BasicAuth>"
}
Figure 2: Stream Creation Operation
Hunt & Ansari Expires January 1, 2018 [Page 10]
Internet-Draft draft-hunt-secevent-usecases June 2017
Note: If the Transmitter does not have an HTTP credential to send
events, the receiver should include one in its registration POST
request or negotiate one out-of-band.
In the stream configuration there is likely a definition as to what
types of events (event families) and which subjects constitute the
feed. In SCIM this will likely be a group of objects, or filter
condition such as "roles" eq "CRM_Users". This is likely based on
the relationship between parties that determines which entities are
provisioned between domains.
Upon successful creation of the Stream, the SCIM Event Transmitter
Responds with:
HTTP/1.1 201 Created
Location: https://events.bighost.com/Streams/2819c223-7f76-453a
{ "receiverId":"<client-id>",
"method":"webCallBack",
"receiverUri":"https://set.example.com/events/",
"aud":"<client-id>",
"type":"SCIM",
"receiverJwkUri":"<receiver's public key url>",
"authorization":"<btoken|BasicAuth>",
"status":"on"
}
Note that in the above figure, the Location URI is the fixed
reference to the Stream for as long as it exists. Administrative
users and Event Receiver entities MAY use the location to check
status or update configuration as needed.
Figure 3: Stream Creation Response
[[TBD, the event receiver, needs to issue the event transmitter a
credential in order for it to issue HTTP POSTs to the Event Receivers
callback endpoint. In some cases there may be an existing OpenID
Connect relationship but in most cases this not expected - especially
in directory-to-directory synchronization scenarios.]]
Stream Verification:
During the initial stream creation request and at any point the
transmitter deems appropriate (e.g. as a ping), the transmitter
verifies configuration by sending a verification event to the
receiver that demonstrates the receiver:
o is willing accept the event, and
Hunt & Ansari Expires January 1, 2018 [Page 11]
Internet-Draft draft-hunt-secevent-usecases June 2017
o is able to parse the event - especially if encrypted.
Conversely an Event Receiver should be able to initiate a
verification request and may provide a confirmation challenge and
nonce to verify the relationship from the Event Receiver's
perspective.
Delivery:
Delivery is accomplished by doing a simple HTTP POST to the
registered endpoint of the receiver. The payload of the POST is
application/jwt and contains a single JWT (which is actually a SET).
Before responding with a 2xx success message, the receiver should
ensure it was able to read and validate the SET. If the transmitter
receives a 2xx response, the transmitter may assume the event was
successfully delivered.
A set of Status 400 error conditions are defined which the receiver
can use to indicate various JWT validation conditions.
4.2. Scenario 2[P0]: Cloud-to-Enterprise POLLING
Pre-conditions:
The Event Receiver already has SCIM access to the Event
Transmitter service provider. This includes HTTP credentials and
endpoint.
Event Receivers and Transmitters can agree out-of-band on SET/JWT
security requirements including use of signing and/or encryption
to be documented in a Stream Configuration.
The Event Receiver is unable to open an endpoint to receive SETs
inside the firewall.
Hunt & Ansari Expires January 1, 2018 [Page 12]
Internet-Draft draft-hunt-secevent-usecases June 2017
+----------------+--------+
| SCIM | SCIM |
|Service Provider| Events |
| | |
+--------^-------+--^-----+
SCIM| |Events via
Commands| |HTTP GET Long Poll
| |& POST Acks
Firewall | |
+---------------------------------------+
| |
+-+----------+-+
| SCIM Client |
| Provisioning |
| Controller |
+--------------+
Figure 4: Event Delivery with Firewall
In Figure 4, the SCIM client initiates RESTful SCIM commands to a
SCIM service provider. In addition to provisioning security objects
such as Users and Groups, the client also uses SCIM to provision
Event Streams in order to receive Events to an endpoint the
provisioning controller requests. In this case, the SCIM Client
"polls" for events using HTTP GET. The client MAY request immediate
response based on a timed schedule, or the client MAY use HTTP Long
Polling to wait for SETs as they become available.
Stream Creation Flow:
The Event Receiver uses their SCIM credential to access the SCIM
service provider endpoint to create a Stream resource by performing a
POST
POST /Streams
Host: scim.bighost.com
Authorization: Bearer h480djs93hd8
{ "receiverId":"<client-id>",
"method":"POLLING",
"aud":"<client-id>",
"type":"SCIM",
"receiverJwkUri":"<receiver's public key url>"
}
Figure 5: Create Polling Stream
Hunt & Ansari Expires January 1, 2018 [Page 13]
Internet-Draft draft-hunt-secevent-usecases June 2017
It is assumed, but may not always be true. that the POLLING receiver
can simply use their SCIM credential to perform HTTP GETs to the
polling endpoint. Additional parameters will likely need to be
defined to control polling rate, number of events in a message, etc.
Note, in the stream configuration there is likely a definition as to
what types of events (event families) and which subjects constitute
the feed. In SCIM this will likely be a group of objects, or filter
condition such as "roles" eq "CRM_Users". This is likely based on
the relationship between parties that determines which entities are
provisioned between domains.
Upon successful creation of the stream, the transmitter responds to
the receiver with:
HTTP/1.1 201 Created
Location: https://events.bighost.com/Streams/2819c223-7f76-453a
{ "receiverId":"<client-id>",
"method":"POLLING",
"receiverUri":"https://set.bighost.com/Events/2819c223-7f76-453a",
"aud":"<client-id>",
"type":"SCIM",
"receiverJwkUri":"<receiver's public key url>",
"status":"on"
}
Figure 6: Polling Stream Creation Response
In the above response, the transmitter indicates to the receiver
where to poll for events by setting a value for "receiverUri". This
endpoint does not need to be SCIM compliant and can be a generic
(e.g. shared by all polliers) endpoint such as
"https://events.bighost.com".
Stream Verification:
Same requirements are for Scenario 1 (see Section 4.1).
Delivery:
Delivery is accomplished by having the Event Receiver initiate an
HTTP request that causes a response such as:
Hunt & Ansari Expires January 1, 2018 [Page 14]
Internet-Draft draft-hunt-secevent-usecases June 2017
{
"sets":{
"4d3559ec67504aaba65d40b0363faad8":
"eyJhbGciOiJub25lIn0
.
e3sgIAogICJqdGkiOiAiNGQzNTU5ZWM2NzUwNGFhYmE2NWQ0MGIwMzYzZmFhZDgiLAog
ICJpYXQiOiAxNDU4NDk2NDA0LAogICJpc3MiOiAiaHR0cHM6Ly9zY2ltLmV4YW1wbGUu
Y29tIiwgIAogICJhdWQiOiBbCiAgICJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vRmVl
ZHMvOThkNTI0NjFmYTViYmM4Nzk1OTNiNzc1NCIsCiAgICJodHRwczovL3NjaW0uZXhh
bXBsZS5jb20vRmVlZHMvNWQ3NjA0NTE2YjFkMDg2NDFkNzY3NmVlNyIKICBdLCAgCiAg
CiAgImV2ZW50cyI6IHsKICAgICJ1cm46aWV0ZjpwYXJhbXM6c2NpbTpldmVudDpjcmVh
dGUiOiB7CiAgICAgICJyZWYiOgogICAgICAgICJodHRwczovL3NjaW0uZXhhbXBsZS5j
b20vVXNlcnMvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsCiAgICAgICJhdHRyaWJ1
dGVzIjpbImlkIiwgIm5hbWUiLCAidXNlck5hbWUiLCAicGFzc3dvcmQiLCAiZW1haWxz
Il0KICAgIH0KICB9Cn0",
"<nextJti>":"<nextJwt>"
},
"since":1458496025
}
Figure 7: Example Polling Response
In the above JSON object is a JSON attribute "sets" whose value is a
JSON object that contains a set of JSON attributes that correspond to
each event's JTI value. the value for each attribute is the actual
encoded SET.
In addition to the "sets" attribute, a "since" attribute indicates
the timestamp of either the last event previously transmitted or
potentially oldest event in the current payload (To be discussed).
In order to acknowledge receipt, the receiver must successfully parse
each message and respond by doing an HTTP POST back to the events
endpoint using something along the lines of the following JSON
structure:
Hunt & Ansari Expires January 1, 2018 [Page 15]
Internet-Draft draft-hunt-secevent-usecases June 2017
{
"ack":[
"39e48e70e9f84d90b5fdbf2fbd826219",
"8e1ed13b871547ffa332f7027a0fdd91",
"0a02c62529e34541a8b3c5c7941fa545"
]
"setErrs":{
"3d0c3cf797584bd193bd0fb1bd4e7d30":{
"err":"dup",
"description":"SET already received. Ignored."
}
}
}
Figure 8: Poll Acknowledgement Response
In the payload above the receiver indicates which SET event JTIs have
been accepted, and which SETs had errors using "accepts" and
"setErrs".
It is expected that because most errors are due to JWT crypto
configuration errors, that most responses will tend to be all errors
or all accepts.
If a transmitter receives what it deems an unrecoverable error, or a
receiver fails to poll for events, the transmitter can set the stream
state to "failed" with an appropriate error indicator.
4.3. Scenario 3[P2]: Cloud-to-Mobile Application PUSH
This scenario is a hybrid of scenario 1 and 2. The scenario uses
mobile message delivery services (APNS, GMS, SMS) to deliver events.
Typically a stream has only one subject in its feed. The events are
used to notify client applications about changes to entitlements, or
other configuration (e.g. new tenancy endpoints)that might be useful
to user experience.
As in the polling method in Scenario 2, to acknowledge events, the
mobile app will need to use the POST (as defined in Scenario 2) to
acknowledge SET delivery. To be discussed, this might not be
necessary if assured delivery is not required.
5. Security Considerations
None as this is a use case document to describe considerations.
Hunt & Ansari Expires January 1, 2018 [Page 16]
Internet-Draft draft-hunt-secevent-usecases June 2017
6. Privacy Considerations
None as this is a use case document to describe considerations.
7. IANA Considerations
There are no IANA considerations.
8. References
8.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,
<http://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,
<http://www.rfc-editor.org/info/rfc3986>.
8.2. Informative References
[I-D.hunt-idevent-scim]
Hunt, P., Denniss, W., and M. Ansari, "SCIM Event
Extension", draft-hunt-idevent-scim-00 (work in progress),
March 2016.
[I-D.ietf-secevent-token]
Hunt, P., Denniss, W., Ansari, M., and M. Jones, "Security
Event Token (SET)", draft-ietf-secevent-token-00 (work in
progress), January 2017.
[I-D.mcmurtry-scim-polling]
McMurtry, C., "SCIM Polling Protocol", draft-mcmurtry-
scim-polling-01 (work in progress), April 2016.
[idevent-scim]
Oracle Corporation, "SCIM Event Extensions (work in
progress)".
[openid-connect-core]
NRI, "OpenID Connect Core 1.0", Nov 2014.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
Hunt & Ansari Expires January 1, 2018 [Page 17]
Internet-Draft draft-hunt-secevent-usecases June 2017
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[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,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC761] USC, "TRANSMISSION CONTROL PROTOCOL", January 1980.
[RFC7642] LI, K., Ed., Hunt, P., Khasnabish, B., Nadalin, A., and Z.
Zeltsan, "System for Cross-domain Identity Management:
Definitions, Overview, Concepts, and Requirements",
RFC 7642, DOI 10.17487/RFC7642, September 2015,
<http://www.rfc-editor.org/info/rfc7642>.
[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, <http://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, <http://www.rfc-editor.org/info/rfc7644>.
[saml-core-2.0]
Internet2, "Assertions and Protocols for the OASIS
Security Assertion Markup Language (SAML) V2.0", March
2005.
Appendix A. Acknowledgments
The editors would like to thanks the members of the SCIM WG which
began discussions of provisioning events starting with: draft-hunt-
scim-notify-00 in 2015.
The editor would like to thank the participants in the the SECEVENTS
working group for their support of this specification.
Appendix B. Change Log
Draft 00 - PH - Initial draft
Hunt & Ansari Expires January 1, 2018 [Page 18]
Internet-Draft draft-hunt-secevent-usecases June 2017
Authors' Addresses
Phil Hunt (editor)
Oracle Corporation
Email: phil.hunt@yahoo.com
Morteza Ansari
Cisco
Email: moransar@cisco.com
Hunt & Ansari Expires January 1, 2018 [Page 19]