0 comments
Cloud 
Om goed de afweging te kunnen maken waarom we ineens naar een Claims based security model gaan, zullen we eerst even naar het verleden moeten kijken welke problemen en uitdagingen we hadden.
Het verleden
De eerste keuze bij Web applicaties op Windows platformen is altijd: Kies ik voor Windows (NTLM/kerberos) security, of voor Forms based Authentication. Deze keuze ligt voor de rest van de applicatie lifetime vast.
Bij het maken van een applicatie op het Java platform is die keuze nog moeilijker, daar komen ook nog allerlei LDAP mogelijkheden om de hoek kijken. Ook is daar de Windows (NTLM/kerberos) security bijna nooit in gebruik, omdat de applicatie dan in een IIS gehangen zal moeten worden.
Zijn we vervolgens aangelogd dan liepen we tegen het volgende probleem aan: welke rechten heeft een persoon. Bij de Windows (NTLM/kerberos) variant krijg ik de user inclusief alle groepen terug (uit de Active Directory). En bij Forms based moet ik zelf een database met alle rollen aanleggen. In beide gevallen ben ik beperkt tot groepen/rollen en kan ik geen extra informatie gemakkelijk toevoegen.
De laatste beperking ligt bij een Single Sign On (SSO) ervaring. Op het intranet is dit met de Windows varianten automatisch geregeld. Voor internet applicaties is dit bijna niet te doen.
Het heden
Microsoft heeft groot ingezet op SAML (Security Assertion Markup Language), dit is een XML gebaseerde open standaard. Omdat het een XML formaat is zijn we niet meer beperkt tot groepen/rollen. We kunnen nu ook bijvoorbeeld een personeelsnummer, leeftijd, of locatie toevoegen.
Deze vorm van Claims based security vinden we zelfs standaard terug in SharePoint.
De claim wordt uitgedeeld door een Security Token Service (STS) ook wel Identity Provider genoemd. Hier gaan we in een later artikel uitgebreid naar kijken. Belangrijkste is dat de STS een Claim voor ons aanmaakt en deze ook digitaal ondertekend zodat de afkomst bekend is.
De applicatie hoeft niet meer zelf voor een login scherm te zorgen, en het hele gebruikersbeheer ligt buiten de applicatie. We controleren alleen de claim of deze van een verttrouwde partij afkomstig is.
Wat staat er in een claim
Dat is een afspraak tussen de STS (Identity Provider) en je applicatie. Iedere applicatie krijgt dus een claim op maat per gebruiker.
We vinden hier in ieder geval de naam van de identity provider en vaak ook de unieke identifier van de user. Daarnaast mogen de volledige naam en alle rollen aanwezig zijn, echter deze zijn niet verplicht!
Voor sommige applicaties kan het handig zijn om al een personeelsnummer, klantnummer, bedrijfsnaam of iets dergelijks in een claim mee te krijgen. De applicatie hoeft dan minder informatie op te zoeken.
Waar moeten we op letten
Te kleine claims zullen resulteren in applicaties die zelf weer databases met rollen en rechten gaan maken. Zorg er in ieder geval voor dat dit zoveel mogelijk gecentraliseerd opgeslagen wordt.
Aan de andere kant bij te grote claims zal er vertraging optreden omdat het versturen en controleren te lang duurt. Ideale oplossing voor dit probleem is om niet alle detail rechten in de claim op te slaan. Denk aan de CRUD rechten voor 100 entiteiten, dat zouden dan 400 claims kunnen worden. Sla dit soort structuren niet op in een Claim, maar genereer ze in de applicatie en bewaar deze in een Sessie of een Cache object.
Mogelijk ander alternatief zou een soort binaire claim kunnen zijn. Hier zul je zelf alle infrastructuur voor moeten schrijven. Qua transport is dit wel weer efficient, voor het debuggen weer niet.
De toekomst
Het zelf bouwen van loginschermen in iedere applicatie zullen we steeds minder tegen gaan komen. Onder andere Microsoft zet groot in op claims, omdat op deze manier een naadloze integratie tussen lokale gebruikers en diensten met de cloud mogelijk is.
Verder hebben we niet te maken met een vendor lock-in qua claims, deze zijn open en kunnen ook uit een Oracle, IBM of OpenSAML pakket komen.