28.07.2013 Views

Claims based Identity and access control

Claims based Identity and access control

Claims based Identity and access control

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Claims</strong> <strong>based</strong> identity <strong>and</strong> <strong>access</strong><br />

<strong>control</strong> – sikker ”tilgang på tvers”<br />

Eirik Mangseth,<br />

Seniorrådgiver,<br />

Avdeling eHelse,<br />

Helsedirektoratet


1. Begreper


Hvem er jeg?<br />

Hvem er du?


Et spørsmål om<br />

identitet


Hvem du er,<br />

avhenger av<br />

konteksten


I en forretningssammenheng er<br />

identitet et operasjonelt konsept.<br />

Dvs., identitet er de fakta om et<br />

subjekt som er relevante i den gitte<br />

sammenhengen.


Faktaene og privilegiene kan vi kalle fordringer eller<br />

påst<strong>and</strong>er (eng. claims).<br />

Påst<strong>and</strong>sbasert identitet = identitet basert på et sett med<br />

fakta og privilegier


Bruk av påst<strong>and</strong>sbasert identitet<br />

fordrer et eksplisitt tillitsforhold med<br />

en såkalt utsteder (eng. issuer).<br />

En applikasjon tror på en eller<br />

flere påst<strong>and</strong>er om en bruker,<br />

kun hvis applikasjonen stoler<br />

på den som utstedte<br />

påst<strong>and</strong>ssettet.<br />

”You have to decide who you trust,<br />

before you decide what to believe”


Et sett med påst<strong>and</strong>er kalles et sikkerhetskjennemerke (SKM) (eng.<br />

security token).<br />

Hvert sikkerhetskjennemerke signeres digitalt av den som har utstedt<br />

kjennemerket.<br />

En påst<strong>and</strong>sbasert applikasjon aksepterer at brukerne er autentisert hvis<br />

de kan fremvise et gyldig, signert sikkerhetskjennemerke fra en utsteder<br />

man har et tillitsforhold til.<br />

1. Autentisering<br />

Utsteder<br />

2. Utstede<br />

SKM<br />

3. Sende<br />

SKM<br />

Applikasjon


St<strong>and</strong>ardbasert<br />

• Dagens løsninger er basert på åpne<br />

st<strong>and</strong>arder, eks,<br />

• WS-Trust<br />

• WS-Federation<br />

• SAML<br />

• o.a.


Oppsummering så langt<br />

• Påst<strong>and</strong> (eng. claim): et faktum<br />

• Sikkerhetskjennemerke (eng. security token): Et<br />

(signert) sett med påst<strong>and</strong>er<br />

• Påst<strong>and</strong>sbasert identitet (eng. claims <strong>based</strong> identity):<br />

identitet basert på et sett med fakta og privilegier<br />

• Påst<strong>and</strong>sbasert sikkerhet (eng. claims <strong>based</strong><br />

security): Autentisering og autorisering basert på<br />

påst<strong>and</strong>er.<br />

• Utsteder (eng. Issuer or <strong>Identity</strong> provider): den som<br />

utsteder gyldige og signerte sikkerhetskjennemerker


Oppsummering så langt<br />

• Påst<strong>and</strong>sbasert sikkerhet<br />

• Frakopling av autentiseringsmekanismen fra<br />

applikasjoner og tjenester<br />

• Erstatter roller med påst<strong>and</strong>er/påst<strong>and</strong>ssett som<br />

en mer finkornet autentiserings- og<br />

autoriseringsmekanisme<br />

• Støtter scenarioer basert på føderert sikkerhet


Oppsummering så langt<br />

• Føderert sikkerhet<br />

• Samme fordeler som for påst<strong>and</strong>sbasert sikkerhet<br />

• Autentisering delegeres til en annen tjeneste,<br />

påst<strong>and</strong>er pakkes inn i et såkalt<br />

sikkerhetskjennemerke<br />

• Kan gi brukere i domener man stoler på tilgang til<br />

applikasjoner og funksjonalitet i eget domene, les<br />

”tilgang på tvers”<br />

• Støtter ”Single Sign-On”


2. Utfordringsbildet


Utfordringsbildet<br />

Kunne støtte forskjellige akkreditiver (eng.<br />

credentials)<br />

Manglende fleksibilitet i rollebasert sikkerhet<br />

Opprettelse og sletting av eksterne brukere<br />

Synkronisering på tvers av domener<br />

Etablere tillitsforhold mellom forskjellige<br />

sikkerhetsdomener<br />

Single sign-on<br />

Sikkker ”tilgang på tvers”


3. Scenarioer


Mine Resepter, en borgertjeneste<br />

3. Log-in<br />

ID-porten<br />

1. Initiell<br />

anmodning<br />

om tilgang<br />

Mine Resepter<br />

(web-applikasjon)


NPO (kun et konsept)<br />

3. Log-in<br />

”HelseID-porten”<br />

Nasjonal<br />

Pasientoversikt<br />

(web-applikasjon)<br />

NPO<br />

(web-service)


NPO (fremdeles kun et konsept)<br />

1. Log-in<br />

”HelseID-porten”<br />

EPJ<br />

2. Utstede<br />

SKM<br />

3. Forespørsel om<br />

data. SKM presenteres<br />

for web-servicen<br />

NPO<br />

(web-service)<br />

En ”smart-client”, for eksempel et EPJ-system, vil på forhånd vite hvilke<br />

utstedere den skal benytte, mens en nettleser må omdirigeres til den eller de<br />

utstederne som nettstedet har et tillitsforhold med.


NPO (fremdeles kun et konsept)<br />

NPO<br />

(web-service)<br />

?<br />

Idp<br />

(dvs. utstedere)<br />

Reseptformidleren<br />

NHN<br />

Helsetjenesteytere<br />

Andre tjenester<br />

Utstederne ovenfor kan spille rollen som påst<strong>and</strong>somformere, dvs. de tar et sett<br />

med påst<strong>and</strong>er som input og omformer disse slik at de blir tilpasset mottaker før<br />

de oversendes mottaker.


Påst<strong>and</strong><br />

Påst<strong>and</strong>sbasert identitet<br />

og<br />

føderert sikkerhet<br />

danner det tekniske grunnlaget<br />

for<br />

sikker ”tilgang på tvers”


Tillit


Takk for oppmerksomheten

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!