Van RBAC naar ABAC deel 5

Dit blog is een onderdeel van de 'Van RBAC naar ABAC' serie. Eerder werden deel 1, deel 2, deel 3 en deel 4 gepubliceerd. Het is aan te raden deze delen eerst te lezen voor verder te gaan met onderstaande tekst.

Bouwblokken

Migratie van RBAC naar ABAC heeft enorme impact. Wil je echt een integrale migratie doormaken, dan moet het applicatielandschap veranderen. Daar waar een applicatie op een stabiele wijze accounts aan rollen en daardoor aan autorisaties koppelt, moet nu een andere autorisatieparadigma worden gekozen: In het geval van ABAC is er geen sprake meer van accounts en rollen, maar is er alleen een webservice interface, of een application programming interface (API) die wacht op een aanvraag en die niets anders doet dan de aanvraag uitvoeren. In ABAC termen is de aanvrager altijd gerechtigd de aanvraag in te dienen en zal de applicatie, de Service Provider (SP), keurig doen wat er gevraagd wordt. Alhoewel, nee, dat is toch niet helemaal het geval. Als we spreken over ABAC, dan praten we inderdaad niet over accounts en rollen, maar wel over autorisaties en niet iedere aanvraag is op voorhand geautoriseerd. Dat spel moet worden omgedraaid. Zoals ik al schreef in deel 2, er geldt een ander paradigma: iemand moet een taak uitvoeren en de applicatie moet de autorisatie verschaffen, als dat mag van de eigenaar van de service (die vanuit een proces wordt aangeroepen). Dat betekent dat er afspraken moeten worden gemaakt. En in dit geval is de SP leidend als het gaat om het beschikbaar stellen van autorisaties aan identiteiten die worden geleverd door Identity Providers. Hierdoor is de rol van de applicatie zelf aanzienlijk beperkt. Een groot deel van de logica in de applicatie wordt daarvandaan verplaatst naar de Service Provider. De SP beheert feitelijk de toegang tot de applicatiefuncties, daar hoeft de applicatie niets meer aan te doen. De applicatiefuncties hoeven alleen maar de door de SP toegestane transacties uit te voeren. Als een gebruiker een applicatiefunctie wil benutten, dan kan dat alleen als de SP dat expliciet toestaat.

Maar wat is dan een Service Provider?

Een SP is de interface waar gebruikers met hun browser of (mobiele) app tegenaan spreken. De SP is de enige ingang tot de applicatiefuncties. De SP is in de regel een standaardcomponent die voor de achterliggende applicatie moet worden geconfigureerd. Ik kan niet uitputtend zijn in het benoemen van SP-componenten. Maar te denken valt aan open source componenten als simpleSAMLphp, shibboleth, wso2 Identity server, maar ook alle commerciële leveranciers als Microsoft, IBM en Oracle leveren componenten en applicatieframeworks. Een SP is in de regel een applicatie die gebouwd is volgens moderne federatieve technieken. De SP heeft dus een interface (Webservice of API) die berichten kan ontvangen en die zelf weer kan inprikken op een achterliggend applicatielandschap. Om een Babylonische spraakverwarring te voorkomen, spreekt een SP maar een heel beperkt aantal talen. In hoofdlijn is dat een SAML-bericht, een Oauth-token of een OpenID Connect token. In zo’n bericht, of token, staat welke identiteit gebruik wil maken van de applicatiefunctie en welke attributen bij die identiteit horen. De SP moet natuurlijk wel weten welke identity provider identiteiten aan mag leveren en, als het even kan, welke attributen door die betreffende IDP aangeleverd mogen worden. Dit moet contractueel worden vastgelegd (een Federatieconvenant is een vorm). Ik ga daar in het laatste deel verder op in.

De SP beoordeelt de attributen van de betreffende identiteit en kijkt of die attributen horen bij de securitypolicy die geldt voor de betreffende applicatiefunctie. Binnen een SP komen we termen tegen als Policy Enforcement Point (de toegangspoort) en Policy Decision Point (de component die de regels en attributen analyseert en al dan niet toegang toestaat). Bij de applicatie(functies) komen we het Policy Administration Point (waarin de toegangsregels worden beheerd) en het Policy Information Point (waarin wordt verwezen naar attribute stores) tegen. Zoals te zien is, betekent een dergelijke opsplitsing van de toegangsverlening dat een applicatie compleet herbouwd zou moeten worden. Dat is in de meeste gevallen niet haalbaar, zo modern zijn de meeste applicatielandschappen niet. In onze RBAC-ABAC migratiestrategie gaan we dan ook uit van een ‘slimme’ applicatie, waarbij de toegangsregels in de vorm van rollen worden beheerd. We kunnen de migatie uitvoeren door de Rol als een Attribuut te beschouwen. Dat is een beetje fout, zoals ik al eerder betoogde, maar zo werkt het in ieder geval wel. De intelligentie zit in het definiëren van de rollen. Met een beetje fantasie is dat grotendeels terug te vinden in de PAP…

En de Identity Provider?

Gebruikers kunnen niet in een applicatie inloggen met een gebruikersnaam met een wachtwoord, maar ze moeten wel ergens een uniek identificeerbare identiteit vandaan halen. Gebruikers loggen in bij een IdP, bijvoorbeeld door in te loggen in een Windows netwerk of met een browser bij een andere IdP. Een AD-account is zich niet voldoende, omdat in geval van federatie andere protocollen worden gebruikt dan de standaard Windows authenticatie. Er moet dus een aanvullende component worden gebruik wanneer Active Directory als gebruikersrepository wordt gebruikt. Te denken valt aan ADFS (Active Directory Federation Service), maar ook aan OpenAM, simpleSAMLphp, of Gluu server. Dergelijke componenten kunnen ook andere gebruikersdatabases gebruiken, dat is een zaak van de IdP (-organisatie) zelf.

Onderliggend trust framework - certificaten

De communicatie tussen IdP en SP omvat wel kritische informatie. Er moet vertrouwen bestaan tussen SP en IdP. Daarbij moeten zowel afspraken worden gemaakt als technische maatregelen getroffen. Over de afspraken spreken we in een volgend artikel. Maar de technische relatie is minstens even belangrijk. De communicatie moet beveiligd worden, zowel de betrouwbaarheid als de vertrouwelijkheid moet gegarandeerd zijn. De berichten worden beveiligd met cryptografische middelen. En als basis daarvoor wordt PKI ingezet. SP en IdP wisselen dan ook certificaten uit. Daardoor is de integriteit van de berichten gewaarborgd, zodat een bericht niet vervalst kan worden.

 

In het laatste artikel in deze serie gaan we kort in op de afsprakenset tussen IdP en SP.