Add a module support System for Cross-domain Identity

[nicoe (Nicolas Évrard)]

Rational

Some companies are using SAML to authenticate the users using Tryton. Quite often in this setup the users and groups are managed in some way from the Identity Provider. The synchronisation between the Identity Provider and Tryton in this regard hasn’t been defined yet.

Hopefully there is a standard that has been devised to allow for the automatic exchange of identity information between IT systems: the System for Cross-domain Identity Management.

In this system, Tryton would provide the routes defined in the protocol RFC which defines a REST API enabling the exchange of ressources defined in the schema RFC. Those resources are users and groups, there is also some room for extensions.

When the Identity Provider creates / modify / delete a user / group, it will be the client consuming this REST in order to reflect those changes in Tryton (and probably other services).

Proposal

Creation of a new module crossdomain_identity_managment. This module will expose the required routes to implement the protocol:

• /Users
• /Groups

The schemas share those common attributes:

SCIM Attribute Name	Description	Remarks
id	A unique identifier of the resource.	We’re responsible for providing this. We should probably use uuids for this
externalId	A string that is an identifier used by the provisioning client.	The RFC states that it’s set by the client and that the Service Provider (Tryton) MUST NOT set it. It’s an optional field
meta	A complex field containing metadata (creation date, location, etc) about the resource

Both id and meta are required.

Users

SCIM Attribute Name	Description	Required	Remarks
userName	Tryton’s unique identifier of the user		login field
name	The user name. A complex attribute containing the components of the user name		name field that we will import for the formatted sub-attribute
displayName	The name of the user as it is usualy displayed		name field again. This one should probably take precendence from the one received from name
nickName	Casual way to address the user		We can ignore that
profileURL	An URI pointing to the user’s profile		We can ignore that
title	The user’s title		We can ignore that
userType	Identify the relation between the user and the organization		We can ignore that
preferredLanguage	The user preferred language in the format of the Accept-Language HTTP header		language field
locale	The locale of the user for the purpose of localizing dates, numerical representation		We can ignore that as it’s already encoded in the language in Tryton
timezone	The user’s timezone		We can ignore that
active	An indication of the user administrative status		active field
password	A write only attribute allowing to set / compare the user’s password		password field. If password authentication is allowed.
emails	A list of email addresses as complex attributes		email field. As we support only one email per user, we should probably use the one marked as primary or the first one with the type work or the first one
phoneNumbers	A list of phone numbers		We can ignore that
ims	A list of instant messaging address		We can ignore that
photos	A list of URIs pointing to the user’s image		avatars field
addresses	A list of physical addresses which are a complex type		We can ignore that
groups	A readonly list of groups the user belongs to		group membership changes are applied through the /Groups endpoint
entitlements	A list of entitlements. An entitlement may be an additional right to a thing / object / service		We can ignore that
roles	A list of roles for the user		We might use that with user_role but I think we can ignore that for now
x509Certificates	A list of certificates associated with the user		We can ignore that

Groups

SCIM Attribute Name	Description	Required	Remarks
displayName	Human readable name of the Group		name field
members	A list of members of the Group. Members are complex type with sub attributes value which is the id of a resource and $ref which is the URI of the resource. Resources can be User or Group		users field

An SCIMGroup Model should be created with the purpose of allowing a mapping between the groups in the Identity Provider and the res.group from Tryton. This model will contain

• name field: a Char field containing the displayName
• members field: a Many2Many field containing the res.user from the members definition

An scim_group field on res.group will point to the SCIMGroup in order to add the users defined in the members attribute in each group pointing to the SCIMGroup being created / modified.

A button on the SCIMGroup model will synchronise the data between the SCIMGroup and the res.group.

I propose this slightly complicated process because I expect that on the first synchronisation no SCIMGroup will exist and thus their link to the Tryton group won’t exist either. After the first synchronisation, using the button won’t be necessary as it will be call after each call on the REST API. The button is still useful though if an admin wants to force the synchronisation.