Adgangsstyring for systembrugere

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.