Provisioning: Authentification API


This document describes the Authentification API splited in two parts. Tt details who has access to the provisioning API and who can do what.

Permissions convention

This is the important part of the authentication system. Let's summarize every existing resources and http methods. We will then map profiles to their permissions :

groupsPOSTCreate a new group
 PUTCreate or modify a group
 PATCHPartially modify an existing group
 DELETEDelete a group
 PUTAssigning a user list to a group
 PUTAssigning a user to a group
 PUTAssigning a subgroup to a group
 DELETERemoving a user from a group
 DELETERemoving a subgroup from a group
 GETGetting a group information
 GETGetting the subgroup members of a group
 GETGetting the members of a group
usersPOSTCreate a new user
 PUTModify a user
 PATCHPartially modify an existing user
 DELETEDelete a user
 GETGetting a user
 GETLists all users
profilesGETGetting a profile
 GETLists all profiles
batchesPOSTCreates a new batch
 PUTCommit the batch
 DELETEDiscard the batch
 GETGetting the status of the batch

Then we describes verbs associated to http methods :


The provisioning authorization system does not use roles. It creates dynamically permissions in the format :


That way and except for admin0, a OBM profile has a set of pemissions only on its own domain.

Finally, the table below lists all the default OBM profiles and their permissions on the provisioning API :

admin0It is the higher profile:
adminAdministrator of a domain: (only on its domain)
admin_delegueSame as admin but cannot commit the batchbatches:read,create,delete, users:*, groups:*, profiles:*
editor???users:read, groups:read, profiles:*
usera simple obm userusers:read, groups:read, profiles:*
unknown personan anonymous userno permission

Authentification convention

By default, every requests done against the provisioning system must be authenticated. We currently use basic http authentication which then match password with the appropriate DAO.