Rest & IAM – Part 3 : SCIM

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.

 

 

 

2 thoughts on “Rest & IAM – Part 3 : SCIM

  1. Ik heb toevallig net een REST API voor een XACML PDP en PAP geimplementeerd. Er was even sprake van dat men een REST API voor XACML wilde standaardiseren, maar het is wat rustig geworden op dat vlak.

    Heb je al ervaring met REST en XACML?

    • Momenteel maken we heel klassiek gebruik van XACML via Web Services. Er zijn geen plannen om van REST gebruik te maken.
      Ik denk eigenlijk dat het communicatieprotocol tussen PDP en PEP niet zoveel uitmaakt en maar een klein onderdeel is van het grotere geheel. De grootste uitdaging lijkt mij het schrijven en beheren van de policies. Dat is niet weggelegd voor occasionele gebruikers.

Leave a Reply to Bob Lannoy Cancel reply

Your email address will not be published. Required fields are marked *