De laatste maanden zijn er heel wat berichten te lezen rond identity management standaarden die gebaseerd zijn op REST/JSON gebaseerde frameworks. Dit staat in tegenstelling tot Web Services/XML gebaseerde standaarden.

Deze blog is de start van een kleine reeks rond deze standaarden.

Vooreerst, wat is REST/JSON?

REST staat voor “REpresentational State Transfer” en is (kort gezegd) een client/server architectuur die volledig gericht is op het Internet en het gebruik van HTTP (alhoewel dit niet beperkt is tot HTTP). Men spreekt soms over RESTful web services. De combinatie van een HTTP-methode (GET, PUT, POST, DELETE), een URL en een payload komt overeen met de aanroep van een methode op een server.  Als payload is er typisch keuze tussen XML en JSON. JSON (Javascript Object Notation Syntax) is een voorstelling van een object dat makkelijk interpreteerbaar is in diverse talen.

Een concreet voorbeeld, stel dat deze blog via een REST interface kan aangeroepen worden dan zou de creatie van een nieuwe post als volgt voorgesteld worden in een HTTP-request:

POST /research HTTP/1.1 Host: blogs.smals-mvm.be Content-Type: application/json

{ "title":"Groei van REST & JSON ...", "Body":"De laatste maanden zijn er heel wat ...", "properties": { "author": { "name":"Bob Lannoy","email":"bob.lannoy@smals.be" }, "tags":  [ "rest", "json", "oauth", "scim" ] } }

Gezien dit steunt op web-standaarden kunnen eenvoudig clients zoals wat javascript-code in een browser services aanroepen op een server via REST. Je ziet dan ook dat de API’s van de grote Internetspelers zoals Google, Facebook, Flickr, Twitter allemaal steunen op een dergelijke aanpak.

Je kan uiteraard ook gebruik maken van Web Services maar er komt vaak heel wat machinerie bij kijken die niet zo evident is in talen zoals Javascript.De wereld is uiteraard niet zwart/wit. Je kan gerust REST combineren met XML en gebruik maken van JSON in Web Services.

Identity management, REST en de cloud

Als je server-acties wenst aan te roepen op een server, dan moet je in veel gevallen aangelogd zijn op die server. Daar biedt HTTP(S) al mogelijkheden om een authenticatie uit te voeren, maar dat is niet voldoende in een federatie. In een dergelijk scenario zijn er drie partijen, de client, de server en een vertrouwde derde partij. Een gebruiker zal bij die derde partij inloggen, een bewijs van aanmelding krijgen en dit meegeven bij de aanroep van een server. In de Web Service wereld spreken we dan vaak over standaarden als WS-Security en SAML.

Op het internet en zijn sociale netwerken is er vaak sprake van websites of web-toepassingen die gebruik wensen te maken van de login van Facebook, Google of Twitter. Hiervoor is er sedert 2007 gewerkt aan OAuth, een autorisatieprotocol.

Daarnaast dienen toepassing bij cloud-providers te weten welke gebruikers zich aanmelden. Men kan hiervoor diverse strategieën toepassen zoals een applicatie-afhankelijke user-store of het aansluiten op een bestaande user-store van een organisatie. Het ingeven van gebruikersinformatie, de creatie en het onderhoud van gebruikersaccount heet ‘user provisioning’. Sinds kort is er gestart met een user-provisioning standaard (Simple Cloud Identity Management, kortweg SCIM) die in cloud-scenario’s makkelijk toepasbaar moet zijn.

In volgende blogposts zullen OAuth en SCIM van dichterbij bekeken worden.