april 2009 nummer 2
Trust management als basis voor online vertrouwen
Behavioral information security: attitude, kennis en gedrag bepalend
IBpedia is kennis maken én kennis delen
INFORMATIEBEVEILIGING
Claims Based Access Control goed alternatief voor RBAC?
http://creativecommons.org/licenses/by-sa/3.0/nl/
IB 2 2009.indd 1
24-03-2009 10:07:08
Claims based access control Auteur: André Koot > André Koot is Security Manager bij Univé-VGZ-IZA-Trias. Hij is tevens hoofdredacteur van dit blad en is bereikbaar via
[email protected].
Steeds meer belangrijke bedrijfsapplicaties worden als webtoepassingen in een Service Oriented Architectuur beschikbaar gesteld via het internet. Traditionele methoden voor toegangsbeveiliging zoals RBAC voldoen niet binnen dit architectuurprincipe en ze stellen de organisatie bovendien bloot aan significante beveiligingsrisico’s. In dit artikel presenteer ik een alternatieve methode om webtoepassingen binnen een SOA beter te beveiligen.
Het afgelopen jaar zijn in dit blad diverse
elke identiteit zelf hoeven te autoriseren
Dat maakt al meteen duidelijk dat we niet
artikelen geschreven over het ontwikkelen
voor alle objecten waarvoor het individu
een standaardrol kunnen gebruiken om
en toepassen van Role Based Access
rechten moet hebben.
anonieme internetgebruikers autorisaties
Control. Ik start met het uitwerken van
Het probleem is dat we, om dit principe
te verschaffen. Een standaardrol is per
enkele bezwaren tegen het gebruik van
te kunnen toepassen, wel de identiteiten
definitie te beperkt. Het heeft geen zin om
RBAC in een Service Oriented Architecture.
moeten kennen, willen we ze kunnen
een businesspartner de standaardrol van
De reden hiervoor is dat we in de praktijk
koppelen aan een rol. We moeten in een
klant te geven.
binnen een SOA omgeving diverse
autorisatiebeheersysteem een userid lid
knelpunten tegenkomen op het gebied van
maken van een groep of rol. Maar wat als
toegangscontrole waar we met RBAC niet
we geen userid hebben om te koppelen aan
mee uit de voeten kunnen. Die knelpunten
een rol? Dat lijkt misschien een overbodige
Een tweede groot bezwaar tegen de
moeten wel worden bezien in het licht van
opmerking, maar stel dat een medewerker
traditionele toegangscontrole is dat
het openstellen van een SOA voor toegang
vanaf het internet toegang zoekt tot een
binnen een SOA een identiteit zelf geen
vanaf het internet, denk hierbij aan Web
informatiesysteem. Dat is op zich simpel,
toegang heeft tot backendsystemen.
2.0 toepassingen. Ik heb in een eerdere
de medewerker moet dan maar eerst
Backendsystemen staan achter de
uitgave van dit blad al geschreven over
inloggen. De verificatie van inloggen doen
servicebus. Het is de servicebus, of
het autoriseren in een Web 2.0 omgeving1.
we in de Active Directory (AD) en de user
een gekoppelde processervice, die de
Dit artikel bevat het vervolg hierop, met
krijgt de bij de rol behorende autorisaties.
achterliggende services aanstuurt.
dien verstande dat ik het onderwerp
Maar in een webomgeving die aan een SOA
Een gebruikersidentiteit mag niet
iets verder heb uitgewerkt en dat het
is gekoppeld hebben we niet per definitie
rechtstreeks services aanspreken. Een
voorgestelde concept in de praktijk al eens
een AD. De AD bevindt zich in een veilige
gebruikersidentiteit binnen het portaal
beperkt is getoetst op toepasbaarheid.
omgeving, niet in een DMZ of bij een
mag dan ook geen autorisaties in het
Daar staat tegenover dat het concept als
hosting provider. Bovendien kunnen ook
backendsysteem hebben. Dit zou een
geheel vermoedelijk niet zonder meer in
onbekende identiteiten zich via de website
serieus beveiligingsrisico inhouden.
de grootschalige praktijk uitvoerbaar is.
aanmelden. Denk aan klanten en partners.
Verschillende randvoorwaarden ontbreken
2) In een SOA heeft de identiteit geen autorisaties
Figuur 1 Ontkoppeling door de Service Bus
nog, maar daar kom ik later op terug. Ik laat eerst vier knelpunten van de traditionele access control methoden binnen een SOA en/of Web 2.0 omgeving de revue passeren. 1) RBAC werkt alleen als we identiteiten kunnen koppelen aan rollen Dit is misschien wel de grootste beperking van RBAC. De methodiek impliceert enerzijds het koppelen van een set permissies binnen informatiesystemen aan een rol, anderzijds het koppelen van een identiteit aan diezelfde rol. Het beginsel is fraai, het betekent namelijk dat we niet [1] Verschenen in Informatiebeveiliging 2008 nummer 6
4
• • • • • • Informatiebeveiliging april 2009
IB 2 2009.indd 4
16-03-2009 10:59:26
Wat betekent dat dan voor de rollen die
concept. In essentie betekent RBAC
Medewerker 1 is senior medewerker.
iemand heeft? Niets. Het begrip rol komt
dat elke extra rol ook extra autorisaties
Medewerker 2 is junior medewerker.
in een SOA niet voor. Het RBAC systeem
met zich meebrengt. Het toekennen van
Beiden hebben dezelfde rol. Je kunt je
van een backendsysteem kent de identiteit
meer rollen leidt tot meer autorisaties.
zo voorstellen dat RBAC daarmee niet
van de portaalgebruiker niet en kan dan
En daarbij zouden ook wel eens
uit de voeten kan. Je kunt nu wel de rol
ook de autorisatie van een serviceaanroep
conflicterende autorisaties kunnen
senior en de rol junior apart definiëren,
niet valideren tegen een rol.
ontstaan.
maar het was nu juist de bedoeling van
Er is een kleine uitweg: als je de identiteit
RBAC om het beheer van autorisaties
(het userid met eventuele rollen) in
Bijkomend probleem is dat RBAC geen
te vereenvoudigen. Ook specialisaties
een XML bericht kwijt kunt, dan zou
rekening houdt met de situatie dat er,
van de ene functionaris ten opzichte
een service op basis van de inhoud van
los van de rol, ook andere factoren
van de andere kun je standaard niet
een dergelijk bericht autorisatieregels
invloed kunnen hebben op de effectieve
onderkennen, tenzij je ook daar extra
kunnen toepassen. Maar dat doet
autorisaties. Autorisaties kunnen naast
rollen definieert en de noodzakelijke
enerzijds onrecht aan de eigenschappen
rolgebaseerd ook regel-, content- of
autorisaties per competentie voor iedere
van de webservice standaarden en
contextgebaseerd zijn. Denk bijvoorbeeld
rol apart instelt. In de praktijk zie je
anderzijds betekent dat aanpassen van de
aan de situatie dat iemand nu eens
door dit probleem het aantal rollen
backendservices om het userid attribuut
niet via een kantoorwerkplek, maar via
exploderen. Role Mining is dan een
in een XML-bericht te kunnen herkennen.
een laptop in de trein aan het werk
oplossing om de essentie van de rollen
Als we zelf berichten gaan definiëren, dan
gaat. Of na kantoortijd. Of via een
te vinden, maar ieders functie is toch
zijn ook alleen die services te gebruiken
privé pc. De betreffende medewerker
eigenlijk zo specifiek dat de generieke
die dergelijke aanpassingen aankunnen.
heeft daarmee niet opeens een andere
rollen een miskenning van de individuele
Weg standaarden en minder mogelijkheid
rol, maar de context waarbinnen de rol
capaciteiten zijn.
voor interoperabiliteit en integratie
wordt uitgeoefend is wel verschillend.
met externe (niet door ons beheerde)
En dat kan betekenen dat de effectieve
Conclusie ten aanzien van RBAC en SOA
systemen.
autorisaties wel eens anders zouden
De meeste van deze knelpunten zijn niet
Ontkoppeling van users en de backend
moeten zijn. Denk ook aan horizontale
specifiek RBAC, of specifiek SOA of Web
systemen via de servicebus zorgt ervoor
autorisaties, waarbij twee functionarissen
2.0, maar we hebben er in een RBAC/SOA
dat RBAC niet kan worden toegepast.
weliswaar dezelfde functie en rol hebben,
omgeving wel heel veel last van.
maar beiden slechts een deelverzameling
RBAC en andere autorisatiemechanismen
De systeemaccounts moeten de
van de gegevens mogen raadlpegen. Dat
zijn preventieve maatregelen, er wordt
autorisaties hebben om alle taken van
kan voorkomen doordat ze beiden vanuit
mee beoogd om zo min mogelijk
gebruikers in backendsystemen te kunnen
een andere juridische competentie actief
overschrijding van toegang te laten
uitvoeren. Maar dat is niet precies wat
zijn of binnen een organisatorische
ontstaan en om daarmee op voorhand de
we willen, daarmee zijn we de Control
eenheid door afwijkende privacyregels en
beoogde functiescheiding te realiseren.
volkomen kwijt. In de backendsystemen
beperkingen de werkzaamheden separaat
Maar RBAC werkt niet goed binnen
is immer het systeemaccount de eigenaar
moeten uitvoeren: de ene persoon zou de
een SOA. Zonder additionele en
van alle transacties.
gegevens, waarvoor de ander competent
compenserende maatregelen heeft in
Ontkoppeling maakt het probleem
is, niet eens mogen zien. Beiden hebben
een SOA een service alle autorisaties. En
misschien nog groter: je zou door in
wel dezelfde rol, maar feitelijk niet
iedereen die de betreffende service weet
te breken in de SOA op een door een
dezelfde autorisaties.
aan te spreken heeft daarmee dus ook alle
legitieme account geïnitieerde transactie
autorisaties. In dat geval lopen we dus
kunnen meeliften en je kunnen voordoen
Waar een rol dus autorisaties toevoegt,
als een legitieme gebruiker.
zou de context de autorisaties moeten
Dus moeten we voor de traceerbaarheid
beperken. Maar, zoals gezegd, RBAC
Zo simpel is het, we moeten op zoek naar
alleen al een compenserende maatregel
kan hier niet mee overweg. Er zouden
een ander autorisatieparadigma om in
treffen in de vorm van het realiseren van
aanvullende businessrules gedefinieerd
control te komen. Tenminste, wanneer we
een audittrail. Ik kom daar later op terug,
moeten worden. ‘Rule based acces control’
portalen gebruiken om gebruikers toegang
maar ik verwijs daarnaast ook naar mijn
is dan wellicht de oplossing die daarvoor
te geven tot backend systemen met een
eerdere artikel over Audit Based Access
ingezet kan worden, maar daarmee krijg je
servicebus die zorgt voor het doorsnijden
Control2.
een nieuw beheerprobleem.
van de identiteit– / autorisatieketen.
3) RBAC heeft geen weet van de context
4) RBAC kan niet overweg met
Toegangscontrole
van toegang RBAC is een goed uitgekristalliseerd
eigenschappen van identiteiten Wat te denken van de volgende casus.
een aanzienlijk risico.
Misschien moeten we eerst het begrip toegangscontrole nog eens onder
[2] Informatiebeveiliging nummer 1 uit 2007
Informatiebeveiliging april 2009 • • • • • •
IB 2 2009.indd 5
5
16-03-2009 10:59:29
de loep nemen. Toegangscontrole is
Een Identity Provider verstrekt aan
de Identity Provider te vertrouwen, maar
misschien niet de juiste term. In het
een individu een digitale identiteit
daar kom ik op terug). Daarmee hebben
Engels wordt de term Access Control
en registreert bij die identiteit een of
we dus op de website inderdaad ook geen
niet voor niets gebruikt, het impliceert
meer attributen, de claims. Te denken
interne directory met gebruikersinformatie
dat je de toegang beheerst. Niet zozeer
valt aan standaardinformatie als NAW
(zoals Active Directory) meer nodig. Als
dat je de toegang beperkt, maar eerder
of geboortedatum. De Identity Provider
we niet terug hoeven te grijpen naar een
dat je verantwoording kunt nemen
staat in voor de juistheid van de
directory in de backend, maar kunnen
voor de feitelijk autorisaties. En dat
verstrekte informatie. Afhankelijk van
vertrouwen op het identiteitenbeheer
kan betekenen dat je bewust te veel
het vertrouwen in de IdP is dan sprake
bij de Identity Provider, dan hebben we
autorisaties toestaat, maar dat je wel
van een bewering of van een feit. De
daarmee feitelijk ook bereikt dat we de
weet wat er gebeurt. Als je weet waar je
SAML standaard is een open standaard
identiteit zelf niet hoeven te beheren!
tekortschiet en de verantwoordelijkheid
die door alle belangrijke leveranciers
En daarmee vervalt meteen het eerste
daarvoor kunt dragen, dan ben je wel in
die zich bezighouden met onder meer
grote knelpunt: we kunnen verschillende
control.
Federated Identity Management3 wordt
niet-beheerde identiteiten verschillende
ondersteund. Het begrip claim (bewering)
rollen geven. Mits we de door de Identity
Gesteld dat je het probleem onderkent,
is dan ook een industriestandaard en het
Provider verstrekte rollen (claims)
dan moet je nadenken over de oplossing
interessante is dat we dat mechanisme
kunnen herkennen. Feitelijk ga je dus
van het probleem. Wij hebben die
nu kunnen toepassen als een drager van
een niet-kernactiviteit4 - het beheren van
voor ons in ieder geval gevonden in
autorisatie-informatie.
identiteiten van klanten / partners / et
een nieuwe ontwikkeling, namelijk het toepassen van Identity 2.0
cetera - uitbesteden. Bron: ‘Dick Hardt’, Mary Hodder op Flickr.com
mogelijkheden. Dat was althans voor ons de trigger om het RBAC probleem op een andere manier aan te pakken. Identity 2.0 Identity 2.0 is het gedachtegoed om hergebruik van identiteiten mogelijk te maken. Een individu creëert of verkrijgt een eigen digitale identiteit en kan deze
Claims based access control
identiteit voor verschillende doeleinden toepassen. Het identity 2.0 concept maakt gebruik van verschillende open standaarden, waardoor het hergebruik van digitale identiteiten technisch en in de praktijk ook mogelijk wordt. Bekende verschijningsvormen van digitale identiteiten zijn OpenID en Information Card. Een belangrijke standaard is SAML, Security Assertion Markup Language, een XML variant variant voor het
Laten we eerst even teruggrijpen naar
Vervolgens kunnen we Portaalfuncties
uitwisselen van authenticatie- en
RBAC. Een rol is feitelijk een bewering
beschikbaar stellen op basis van de
autorisatiegegevens. Een van de
over een identiteit. Een identiteit vervult
rol die in het paspoort gedefinieerd is.
berichtensoorten binnen SAML is de
een rol in een organisatie of binnen een
Daarbij moet er een ‘claim-autorisatie
‘claim’, een bewering over een digitale
proces. Een rol is dus te vatten in een
matrix’ bestaan op basis waarvan de
identiteit. De A in SAML staat voor
claim. Als een identity provider (IdP) in
autorisaties worden geëffectueerd.
Assertion, ofwel het na validering van
een digitale identiteit nu ook een rol als
Als de portaalfuncties services starten
een attribuut nemen van een beslissing,
claim vermeldt, dan kunnen we die claim
en als een gebruiker binnen het portaal
een assertion is een vaststaand feit.
gebruiken als autorisatiemechanisme,
alleen kan wat hij op basis van zijn
Een attribuut is een aan een identiteit
zonder dat we in een directory op basis
claims mag en de afhankelijke services
toegekend kenmerk en heet ook wel
van een userid de security bevoegdheden
in de backendsystemen niet rechtstreeks
Claim.
hoeven uit te lezen (we hoeven alleen
kan benaderen, dan maakt het feitelijk
[3] Federation werk ik hier niet verder uit, is wellicht stof voor een andere artikel (wie schrijft?) [4] De vraag is hierbij natuurlijk wat je een kernactiviteit vindt
6
• • • • • • Informatiebeveiliging april 2009
IB 2 2009.indd 6
16-03-2009 10:59:30
ook niet uit dat een serviceaccount
bepaalde capaciteiten bezit, dat die
van senior of junior medewerker (jaren
alle rechten heeft. Daarmee hebben we
persoon over bepaalde kennis en
in dienst), of de context van juridische
dus eigenlijk het tweede grote knelpunt
bepaalde vaardigheden beschikt. Dat de
entiteit 1 of 2, is te vervatten in
weggenomen. We moeten autoriseren
uitvoerende een bepaalde anciënniteit
Assertions. Andere aspecten van context,
buiten de servicebus, aan de frontends.
bezit. Oftewel: de proceseigenaar wil
zoals kanaal of soort werktijd, zijn met
Dus we gaan niet meer autoriseren in de
dat de uitvoerende bepaalde kenmerken
technische middelen wel te bepalen. Dat
backendsystemen, we gaan autoriseren in
bezit. Of dat de uitvoerende afhankelijk
betekent feitelijk dat we ook het derde en
het portaal en in het proces. Dat is even
van bepaalde kenmerken bepaalde
het vierde knelpunt met claims kunnen
wennen.
processtappen niet uit mag voeren of
adresseren.
Figuur 2 Autorisatie in portaal en/of proces op basis van claims
gegevens niet mag benaderen. En wat zijn dergelijke kenmerken anders dan
We zijn er nog niet helemaal. Als je de oplossing in al zijn eenvoud beschouwt, lijkt het de ideale oplossing. Maar we zijn onze tijd te ver vooruit. Er ontbreken simpelweg enkele randvoorwaarden om dit in productie te kunnen nemen. Ontbrekende randvoorwaarden • Identity Providers Er zijn op dit moment geen Identity Providers die digitale identiteitsbewijzen voorzien van de gewenste kwaliteit van claims (assertions) kunnen leveren. Er zijn wel Identity Providers, maar die leveren op dit moment authenticatieservices. Denk aan DigiD en EasyID van Diginotar. Dat zijn oplossingen waarbij een serviceprovider de authenticatie uitbesteedt aan de Identity Provider. Dat is niet wat we zoeken. We willen het identiteitenbeheer
Laten we het begrip rol nog iets verder
Claims, beweringen over een identiteit.
uitbesteden en de autorisatie in eigen
uitdiepen. Een rol is feitelijk een
Als de proceseigenaar nu eens niet
hand houden. Authenticatie is in dit
verzameling autorisaties waarmee een
bepaalt dat iemand een accountmanager
verhaal niet aan de orde. Begrijp me niet
samenhangend takenpakket kan worden
moet zijn, maar dat een taak alleen
verkeerd: authenticatie is van belang (zie
uitgevoerd. Het takenpakket wordt
mag worden uitgeoefend door iemand
het boek Identity Crisis5), maar dat is
gedefinieerd binnen de bedrijfsvoering,
die een x-aantal jaar in dienst is en
een verdere verdieping van de identiteit.
laten we zeggen dat een proceseigenaar
een bepaald diploma heeft, dan leidt
De authenticatiemethode kan in een
aangeeft welke taken bij elkaar horen
dat meteen tot de conclusie dat het
claim worden vervat. We zoeken een
en hoe de functiescheiding is geregeld.
begrip rol voor de proceseigenaar geen
vertrouwde partij die digitale paspoorten
Het maakt deze proceseigenaar eigenlijk
rol speelt. Functiescheiding is wel een
levert waarop wij onze autorisatie
helemaal niet uit wie de taak uitvoert.
relevant aspect, maar met Audit Based
kunnen baseren. We kunnen zelf allemaal
Het gaat er alleen om dat aan de
Access Control (in combinatie met op
wel een Identity Provider oprichten, maar
kwaliteitseisen die worden gesteld aan
context gebaseerde aanvullende controles
daar zijn we niet bij gebaat. Noch wij,
het proces wordt voldaan. Dat is een
zoals transactielimieten) komen we
als service provider, noch de klant. Wij
interessante stelling. Eigenlijk hoeft
ook een heel eind als het gaat om het
raken dan het proces niet kwijt en de
de proceseigenaar helemaal niet te
toewijzen van verantwoordelijkheid voor
klant heeft nog steeds heel veel digitale
bepalen welke rol welke taken mag
transacties. Iedereen mag alles, ik wil het
identiteiten voor heel veel verschillende
uitvoeren. Hij moet aangeven aan welke
alleen wel kunnen controleren.
doeleinden. We willen graag door
kwaliteitseisen de uitvoering moet
Identity Providers verstrekte digitale
voldoen. En dat is eigenlijk helemaal
Wat we hier effectief mee bereiken is dat
identiteiten kunnen vertrouwen. Dat
nieuw. De proceseigenaar wil eigenlijk
we ook het kwalitatieve begrip context
betekent dan dat we de identity providers
dat iemand die een processtap uitvoert
een plaats kunnen geven. De context
willen vertrouwen. Feitelijk zoeken we
[5] Boekbespreking Identity Crisis in Informatiebeveiliging 1 van 2009
Informatiebeveiliging april 2009 • • • • • •
IB 2 2009.indd 7
7
16-03-2009 10:59:33
voor Identity Providers ook iets als Cross
voorstander van, een dergelijke service
Conclusie
Certification uit de PKI-wereld. Maar
kent immers je gedrag op internet.
Claims Based Access control maakt het
op dit moment bestaat een dergelijke infrastructuur niet. Bron: ‘Passport interior 2’, Jenny Factory op Flicr.com
mogelijk om binnen een een SOA/Web • Audittrail
2.0 omgeving toegangsbeveiliging op
Er zijn nog geen standaarden voor de
een effectieve manier te realiseren.
audittrail. Dit instrument is van belang om
De technieken zijn beschikbaar, de
elke transactie in een backofficesysteem
standaarden zijn aanwezig. Het vergt
te kunnen terugvoeren op een uniek
wel enkele onconventionele methoden
uitgevoerd proces en binnen dat proces
en de vraag is wanneer deze methoden
op alle binnen dat proces acterende
in praktijk gebracht zullen worden. We
identiteiten. Het inrichten van een
kunnen wel willen, maar of we willen
audittrail is ook weer een verhaal op zich.
kunnen, is de vraag.
Je zult bij voorbeeld vast moeten leggen:
Voor de korte termijn levert dat ook wel wat discussie op. Mag het wel? Ofwel: zijn
• Datum/tijd
we eraan toe, accepteren stakeholders
• Gebruikersnaam (van de
en toezichthouders dit samenspel van
portaalgebruiker)
beheersingsmaatregelen?
• Procesidentificatie (unieke identificatie van de ‘instance’ van een gestart proces) • Transactie-identificatie (unieke
Als we voorbijgaan aan het knelpunt van standaardisering dat ontstaat bij
identificatie van de transactie zoals die
het ontsluiten van een SOA voor Web2.0
in het backendsysteem ontstaat of wordt
gebruikers op het internet, dan kunnen
beheerd)
we het mechanisme wel al inzetten voor
Claims based access control
autorisatie binnen een SOA. Daarmee
8
Op die manier kun je via de audittrail in
kunnen we diverse knelpunten alvast
de SOA altijd vaststellen wie binnen welk
wegnemen. Ik zou zeggen: denk hier eens
• Digitale portefeuilles
proces heeft geacteerd. En wie een hand
over na en aarzel niet om te reageren.
Een digitaal paspoort bewaar je in een
heeft gehad in de transactie die in het
digitale portefeuille. Information Card is
backendsysteem is vastgelegd.
een prima bruikbaar paspoort, maar er zijn nog maar weinig mensen die een dergelijk
• Standaarden voor claims
paspoort kunnen gebruiken. De digitale
Er zijn nog geen uitgewerkte standaarden
portefeuille heet in Windows-omgevingen
voor claims. Information Card van
Windows Cardspace en die is standaard
Microsoft kent wel diverse standaard
aanwezig in Windows Vista. Als dat
claims, maar die zijn niet voldoende
product handiger gelanceerd was geweest,
om als basis voor autorisatie te dienen.
dan waren de meeste pc’s nu wel voorzien
Standaardclaims zullen ook niet zomaar
van een digitale portefeuille. Helaas.
toegepast kunnen worden, omdat
Andere systemen moeten handmatig
autorisaties natuurlijk procesgeoriënteerd
worden voorzien van de portefeuille.
zijn. Standaardclaims kunnen alleen aan
Windows XP heeft .NET 3.x nodig, MacOS
gestandaardiseerde autorisaties worden
en Linux kunnen met DigitalMe (van het
gekoppeld. De vraag is of het mogelijk
Eclipse project Bandit, van Novell) uit
zal zijn om te komen tot een min of
de voeten. Maar zoals gezegd, allemaal
meer beperkte standaardisering. Voor
handwerk. Dat betekent dat voor
interne verstrekte claims door interne
reguliere gebruikers, klanten, het digitale
Identity Providers is dat natuurlijk geen
paspoort in de vorm van Information Card
probleem. Niets weerhoudt een organisatie
misschien wel een brug te ver is. Een
ervan om digitale paspoorten met een
alternatief is OpenID, maar dat is ook een
claim ‘Medewerker = accountmanager’ te
authenticatieservice en daar ben ik geen
verstrekken.
• • • • • • Informatiebeveiliging april 2009
IB 2 2009.indd 8
16-03-2009 10:59:36
