[scim] Maintaining SCIM client-side cache consistency with SCIMv2

["Matt Peterson (mpeterso)" <[e-mail]>]

The discussion on this SCIM Interest Group meeting today (recording here: https://www.youtube.com/watch?v=q7Fpf0JfLcM) suggested that it is very common (for various reasons) for relying party applications to keep their own database of identity objects (users and groups).  For example, checking access to an application resource is something that happens frequently enough to justify optimizing with a cache of objects so that the application does not need to query the IDP (using SCIM) for every authorization event.

The in-application database is essentially a "cache" of the users and groups for which the application *is not an authority*.   The Identity Provider is the authority for these objects.   Nevertheless, the application may want to keep its copy of these objects up to date when changes are made to the authoritative objects (on the IDP).  This is especially the case for deleted users, and group membership changes which may have important security/authorization implications for the application.

There are several ways that an application could maintain SCIM Client cache consistency:


  *   Option #0:  Update at login - Inspecting the token (SAML, OIDC, etc)  presented by the authenticated user may allow the application to update user properties in the application cache.
  *   Option #1:  Scheduled polling - The application periodically queries the IDP to fetch users and groups.   Scheduled polling is possible today (with no changes to SCIM), but it could be much more efficient if default SCIM schema included a "update sequence number (USN)" or "LastChangedTime" attribute that could be used by a SCIM client in SCIM filter to get only the objects that have changed since the last time the application polled.
  *   Option #2: Simple Webhook notification - Discussed briefly on recent SCIM workgroup virtual meetings.  This would follow a simple pattern used by many systems for delivering real-time change notifications.  No Internet Draft has been written.
  *   Option #3:  https://tools.ietf.org/html/draft-hunt-scim-notify-00 - an inclusive SCIM notifications proposal that includes multiple notification mechanisms (poll, webhook, RFC 8030 webpush, etc).
  *   Option #4:  https://tools.ietf.org/html/draft-wahl-scim-profile-00 -The IDP (acting as a SCIM client) pushes changes to the application (acting as a SCIM Server).


(All of the following are strongly prefaced with "in my opinion":)

Option #0  is included mainly for completeness.  It's not really a viable option for most applications because it does not allow update of application "cache" until a user logs in -- which will never happen for a deleted user.  It also may require too much application-specific information to be included in tokens - complicating mapping rules for the IDP and transferring authorization responsibilities to the IDP where they would be too distant from the application which knows the details about the resources to which need to be secured.

Option #1 is the easiest to implement because it only requires a simple change to SCIM schema that could be readily implemented by most IDPs (SCIM servers).  It follows a pattern that is been proven by Microsoft Active Directory and compatible applications that use the uSNChanged attribute (see: https://docs.microsoft.com/en-us/windows/win32/ad/polling-for-changes-using-usnchanged).  Option #1 may not be the most elegant solution, but it is the quickest, simplest solution that is most likely to achieve community consensus and interoperable implementations.

Option #2 needs an internet draft, a simple short internet draft describing the webhook.  This simple webhook option may be easier/quicker for driving consensus and interoperable implementations than option #3.

Option #3 is a more elegant and inclusive approach than option #1 and/or option #2.  It includes multiple notification mechanisms (polling, webhook, RFC 8030 web push, etc).  However, it introduces a feed service and other complexities that might make take longer to get community consensus and interoperable implementations.

Option #4 (IMO) invites unnecessary confusion, and complication.   It complicates development of both a SCIM Server (IDP) and the SCIM client (relying party application) by ambiguating the only "profiles" that the community appears to be comfortable with (SCIM Server and SCIM Client).  It proposes that IDPs and Relying Party applications implement the SCIM aspects of the other.  The authentication implementation and configuration pre-requisites for a relying party application (now both a SCIM client and a SCIM server) to authenticate an IDP (now both a SCIM server and a client) would be difficult for most application.

There are already two drafts (referenced above)  that are address the same topic of "Maintaining SCIM client-side cache consistency with SCIMv2".   I think it is worth tackling topic  as a general topic of interest, and *then* charter the draft(s) (or draft revisions) that are most likely to garner the most support and consensus.

--
Matt Peterson
Distinguished Engineer
Quest Software