I dette dokument opridses principperne for adgangsstyring i web
services, der beskyttes af NemLog-in STS.
Grundlæggende kan den enkelte web service ved tilslutning til
NemLog-in STS definere et antal (statiske) roller,
som anvendes
til administration samt håndhævelse af adgang til servicen.
Rollerne er specifikke for servicen og modelleres som privilegier. Et
privilegie repræsenteres som en unik URI, og det anbefales af benytte
en struktur, hvor første del angiver serviceudbyderens domæne som fx:
- http://miniministeriet.dk/services/min_service/roles/rolle_abc
- urn:dk:miniministeriet:servies:min_service:roles:rolle_abc
Herved er entydighed af rolle ID'en sikret.
Organisationen, som tilmelder en web service til NemLog-in, skal
udpege en teknisk administrator.
Administratoren kan i
NemLog-in's administrationsmodul tildele web servicens roller til
klienter (systembrugere) fra andre organisationer, og de vil herefter
optræde i de tokens, som NemLog-in udsteder til disse klienter.
NemLog-in har ingen semantisk forståelse af rollernes indhold - men
videreformidler bare en tildeling til et system.
Roller indkodes i SAML tokenet i henhold til OIO Basic Privilege
Profile (http://digitaliser.dk/resource/2377872).
Et eksempel på en privilegiestruktur er vist nedenfor:
<bpp:PrivilegeList
xmlns:bpp="http://itst.dk/oiosaml/basic_privilege_profile"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier:20374826">
<Privilege>http://miniministeriet.dk/services/min_service/roles/rolle_abc</Privilege>
</PrivilegeGroup>
</bpp:PrivilegeList>
Betydning og indholdet af rollerne for en web service er en
lokal, forretningsmæssig afklaring, som den enkelte serviceudbyder må
foretage.
Nogle services kan have behov for få roller mens andre
kan have behov for mange roller afhængigt af, hvor finkornet en
adgang, som skal kunne tildeles til klienter.
Validering af modtaget token
I det enkelte web service kald skal SAML tokenet medsendes fra
klienten, og web servicen skal som det første validere tokenet.
Tokenvalidering omfatter bl.a. nedenstående (se SAML standarden for
den fulde specifikation af processeringsregler):
- token er
signeret af NemLog-in STS (NemLog-in's certifikat skal inkluderes i
lokalt trust store)
- token er gyldigt og fx ikke udløbet (check
mod lokal tid)
- web service kald er signeret med det certifikat,
som refereres i holder-of-key elementet i token
- web servicens
EntityID er angivet som Audience i token (dvs. token er udstedt mod
denne web service)
Derudover bør token logges i den lokale auditlog med tilhørende ID på
web service kald samt resultat af tokenvalidering.
Først efter succesfuld tokenvalidering kan indholdet trustes, og web
servicen kan udtrække systembrugerens ID samt rollerne angivet i
tokenet.
Herefter gives adgang til operationer og data i web
servicen, som modsvarer rollens indhold - altså de lokale
rettigheder,
som er tilknyttet til rollen.