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.

OAuth is een systeem dat toelaat om aan derde partijen een sleutel te geven waarmee ze op een site toegang krijgen tot jouw gegevens.  Typische voorbeelden zijn (web)toepassingen die toegang wensen tot je Facebook- of Twitter-gegevens.
Je geeft deze toepassingen niet je gebruikersnaam en wachtwoord maar een token waarmee ze toegang verkrijgen. De geldigheid van dit token kan beperkt worden in scope en tijd. Je kan dit token ook “revoken”. Op Twitter is er bijvoorbeeld een pagina (in settings / Applications) waar de lijst met applicaties wordt getoond waarvoor er een token bestaat.

Het principe van OAuth is vrij bekend aangezien het sterk lijkt op processen in federatiestandaarden zoals SAML en WS-Trust. Er zijn drie partijen: de client, de resource owner en de server, respectievelijk user, consumer en Salesforce in de figuur. De client is een stuk software of een dienst die toegang wenst tot resources op een server.

Kort gezegd werkt het als volgt, meer uitleg op de OAuth website:

• De server is bekend met de service die de client aanbiedt. De client dient zich op voorhand te registeren (ze beschikken over een “shared secret”).
• Als de client toegang wil tot bepaalde resources dient hij gebruik te maken van een access token.
• Dit access token wordt verkregen door de resource owner zich te laten aanmelden op de server. Hierdoor krijgt de client eerst een request token dat na validatie wordt ingewisseld voor een access token.
• Met dit access token kan de client dan de toegelaten resources opvragen, binnen de voorwaarden van de resource owner.

Merk op dat er directe communicatie is tussen de client en de server voor het verkrijgen van het access token. OAuth is ook niet beperkt tot implementaties voor pure webapplicaties. Het kan ook dienen voor clients op mobiele toestellen of servers die toegang wensen tot bepaalde resources of gegevens.

OAuth heeft reeds heel wat historiek achter zich. Het is ontstaan uit de OpenID community en is als versie 1.0a geïmplementeerd bij een aantal grote spelers (zoals Twitter). OAuth v1 heeft echter met veel kritiek te maken, met name qua complexiteit. Door het gebruik van digitale handtekeningen is het systeem zeer implementatiegevoelig aan de client-zijde. Aangezien OAuth door velen in de REST-wereld werd gezien als een licht alternatief voor ‘zware’ XML-Security implementaties, viel dit niet in goede aarde.

Daarom werd OAuth 2.0 een volledige herziening van de specificatie en ook ingediend bij IETF ter standaardisatie. Er is hierom echter weer kritiek omdat men op veiligheidsvlak een aantal toegevingen doet om de complexiteit te verlagen. Indien er geen gebruik gemaakt wordt van SSL zijn er serieuze veiligheidsrisico’s. Het gebruik van handtekeningen is nog steeds mogelijk maar niet verplicht.

Google en Facebook maken momenteel gebruik van OAuth 2.0 voor de toegang tot hun APIs.

Zijn de andere federatiestandaarden dan nutteloos? Neen, OAuth kan je ook perfect gebruiken in combinatie met standaarden zoals SAML, zoals hier wordt aangetoond.

Moeten we nu met zijn allen overstappen op OAuth? Natuurlijk niet, maar het is wel belangrijk te weten wat voor standaarden opgang maken bij de grote internetspelers.