In mijn twee vorige posts (deel 1 en deel 2) heb ik gesproken over de opkomst van een REST-gebaseerde aanpak in Identity Management. Grote internetspelers gaan volop voor een naar hun zeggen “eenvoudige en lichte” aanpak, getuige daarvan het massale gebruik van OAuth.

Je kan echter pas iemand authentiseren of toelaten tot je systeem als die gekend is met de nodige set gegevens. Het toevoegen van een gebruiker aan een identiteitsbeheeroplossing heet “provisioning”.

In organisaties zijn de gegevens van een gebruiker sterk verspreid in verschillende systemen: gegevens in de personeelsdatabase, mailsysteem, Windows-domein, adresboek, … Een provisioneringsoplossing zal deze gegevens centraal beheren zodat het toevoegen, wijzigen en het verwijderen van een gebruiker in die verschillende bronnen de nodige operaties zal uitvoeren. De aanpak van dergelijke tools was echter steeds propriëtair. Meerdere provisioneringstools konden moeilijk met elkaar praten. De grote droom van standardisatie en interoperabiliteit werd gerealiseerd in 2003 met SPML (Service Provisioning Markup Language), dat in 2006 aan zijn 2de versie toe was.

Het is echter bij een droom gebleven. SPML is vrij complex en werd vrijwel niet geïmplementeerd in tools. In het voorjaar is er een kaper op de kust verschenen: SCIM (Simple Cloud Identity Management), met als belangrijk ingrediënt (hoe kan het ook anders): cloud.

In omgevingen die meer gedistribueerd zijn met toepassingen en services “in the cloud” bij verschillende leveranciers, wordt het provisioneren van gebruikers vanuit de organisatie een moeilijke klus. Niemand wil zijn honderden gebruikers manueel gaan ingeven bij de SaaS-leverancier. En ja, er zijn integratiemogelijkheden tussen je eigen omgeving en de SaaS-provider maar die zijn specifiek per leverancier.

Daarom wil men via het SCIM provisioneringsprotocol, het provisioneringsproces automatiseren en standardiseren. Grote spelers als Google en Salesforce zijn de drijvende kracht achter deze standaardisatie.

De standaard wil CRUD (Create, Read, Update en Delete) operaties bieden op gebruikersaccounts en dit volgens een beperkt aantal scenario’s. Als onderliggend protocol zal men zich op REST baseren met een JSON-payload. Die payload bevat een inhoud volgens een uitbreidbaar schema, zodat specifieke attributen ook kunnen opgenomen worden.

Een klein voorbeeld uit de draft specificatie van een Request die een gebruiker aanmaakt:

POST /User  HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer h480djs93hd8
Content-Length: ...

{
  "schemas":["urn:scim:schemas:core:1.0"],
  "userName":"bjensen",
  "externalId":"bjensen",
  "name":{
    "formatted":"Ms. Barbara J Jensen III",
    "familyName":"Jensen",
    "givenName":"Barbara"
  }
}

Merk op dat men als authenticatietoken gebruikt maakt van OAuth.

Naast de JSON-representatie wordt er ook gewerkt aan een representatie van het schema in SAML-attributen. Dit laat toe bij gebruik van SAML-tokens voor Single Sign-On om de gebruiker onmiddellijk te provisioneren indien deze nog niet zou bestaan.

Ondanks het feit dat SCIM nog geen standaard is, bestaan er wel al een paar implementaties.

Met OAuth en SCIM zijn twee aspecten van Identity Management vertaald naar een REST-architectuur, nl. authenticatie en provisioning. Rest ons nog autorisaties waar momenteel XACML de meest genoemde standaard is. Het valt nog af te wachten of hiervoor ook een alternatief op de proppen komt.