Add SCIM as a data source

[paulmillar]

From the SCIM (System for Cross-domain Identity Management) homepage:

The System for Cross-domain Identity Management (SCIM) specification is designed to make managing user identities in cloud-based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence: make it fast, cheap, and easy to move users in to, out of, and around the cloud.

SCIM 2.0 is released as RFC7642 (core schema), RFC7643 (protocol) and RFC7644 (overview, etc.).

SCIM concepts include "group" and "user", where a group contains users and a user has email addresses (if multiple, one may be labelled the primary email address).

Expected Behavior

There would be a data source that accepts a SCIM group as configuration. There are a few ways the group could be identified:

• the OIDC issuer and group name,
• the SCIM endpoint and the group name,
• the SCIM group URL.

The data source would query the group endpoint to discover a list of users IDs and references. This will likely happen periodically. The data source may allow the period to be configurable. The data source may allow the list admin to trigger this discovery process explicitly. The data source may allow an external application to trigger the discovery process.

When triggered, the data source would run a reconciliation procedure that would harmonise the SCIM group membership with the Symba list membership. In other words, the data source would fetch the SCIM JSON group description and identifying the members of that SCIM group. The data source would add to the Sympa list any SCIM group member that is not already a member of the Sympa list, and remove any Sympa list member who was previously added from the SCIM group and is no longer a member of the SCIM group.

Care would be needed to avoid adding a SCIM group member who was added to the Sympa list through some other (non-SCIM) route.

When adding a new SCIM member, the data source would fetch the SCIM JSON user description. This is used to identify that user's name and email address.

If the SCIM JSON user description contains a single email address then that address is used. If the user has multiple email addresses then the data source would employ different strategies to select a single email address; for example, selecting the primary email address, selecting the address of type "work", etc. The data source could employ these strategies one after the other until a single email address is selected. If the series of employed strategies fails to identify a single email address then that SCIM user is not added to the Sympa list. The data source may expose the choice of which strategies to employ and in which order as configuration.

In many cases, access to a SCIM endpoint is protected and requires some form of authentication. The data source should support common authentication mechanisms; for example, allowing a list admin to specify a bearer token (such as an OAuth2 access token) as configuration.

Current Behavior

Sympa currently does not support SCIM.

Possible Solution

A data source is written as a SCIM client, which makes HTTP requests to fetch information, as necessary.

It might be possible to run a service that obtains SCIM information and makes it available as LDAP, then configure a LDAP-based data source. This approach is less desirable, as it requires running at least one additional service.

Context

I am interested in Sympa providing a mailing list that allows emails to be sent to all members of some group. The group-membership is not managed within Sympa, but with an external authentication service, which exposes this information via SCIM.

To be more precise, the external service is a "community proxy" (as per the AARC Blueprint Architecture). In addition to supporting OIDC-based authentication, the service also asserts and manages group membership. The service will "soon" provide support for SCIM, as per the OIDC profile for SCIM.