OISAML Workshop Århus 31. marts 2009

Præsentationer af emnet: "OISAML Workshop Århus 31. marts 2009"— Præsentationens transcript:

1 OISAML Workshop Århus 31. marts 2009
Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen -

2 Velkommen! Dette er en WORKSHOP – Ikke et fintunet kursus!!

3 Agenda – første del 10.00 Velkomst og Introduktion
Overordnet introduktion til OIOSAML og OIOIDWS 11.15 Opsplitning Dem der skal lave.Net hands-on går til Trifork, Margrethepladsen 4 - Resten bliver Udviklingsplanen for FOBS - v. Ellen Syberg Info om kurser i tilslutning - v. Thomas Gundel Opsætning af lokal test IdP - v. Thomas Gundel Introduktion til Digitaliser.dk v. Martin Høegh Mortensen 13.00 Alle går til Margretepladsen 4

4 Agenda – anden del 13.25 Opsplitning
Dem der skal lave Java hands-on bliver hos Trifork, Resten går tilbage til hotellet Introduktion til Digitaliser.dk v. Martin Høegh Mortensen Erfaring med integration af OIOSAML.NET I konkret produkt (Umbraco) - v. Thomas Ravnholt Microsoft's understøttelse af SAML v. Rene Løhde – Microsoft 14.45 Pause – Alle samles 15.00 Brugerstyringsmønstre – herunder sammenhængende log-in - v. Søren Peter Nielsen Plenum: Spørgsmål og svar; Hvor er barrierene? Indtil Fri erfaringsudveksling

5 Folk, som det er værd at kende i dag
Joakim Recht og Preben Thorø – Trifork OIOSAML og OIOIDWS Referenceimplementeringer Thomas Gundel – IT Crew OIOSAML og OIOIDWS standarder & NemLog-in Klaus Byskov Hoffmann – Safewhere OIOSAML.NET Nana Below – EogS & Brian Nielsen – ITST Virk BRS Ellen Syberg – Økonomistyrelsen Brugerstyringssekretariatet

6 Overordnet introduktion til OIOSAML og OIOIDWS
Begge standarder giver en interoperabel måde at give svar på tværs af sikkerhedsdomæner på: Hvem er brugeren? Hvad må brugeren? OISAML 2.0 retter sig mod browser-baserede løsninger OIOIDWS retter sig mod SOAP-baserede webservices

7 OIOSAML 2.0 OIOSAML 2.0 er en profil af OASIS SAML 2.0
Profilen beskriver det subset af SAML 2.0 standarden, som er relevant i en dansk kontekst og sikrer ”fælles sporbredde” for integration tværs af organisatoriske skel og tekniske platforme SAML 2.0 er DeFacto standarden for federation

8 Roller Loginløsning Identity Provider (IdP) Bruger Serviceudbyder
Service Provider (SP) SP SAML = Security Assertion Markup Language

9 Etablering af tillid IdP Metadata: IdP certifikater og endpoints
Metadata: SP certifikater og endpoints IdP Metadata: IdP certifikater og endpoints SP

10 SP-initieret login IdP SP Step 3: ©
User authenticates to the IdP and gets session cookie as well as common domain cookie c Saml_idp IdP Step 2: The SP has no session with the user, and redirects the user to its default IdP with AuthNRequest Step 4: …signed and encrypted SAML assertion w user id and attributes is sent to SP with POST binding Step 1: User goes to the SP SP

11 SP-initieret SSO SSO IdP SP © ©
Step 2: The SP reads which IdP the user has logged into from the common domain cookie, and redirects the user to that IdP with AuthNRequest c IdP c Saml_idp Step 3: The IdP reads the session cookie (or similar) and determines that the user is already logged in and… …signed and encrypted SAML assertion w user id and attributes is sent to SP with POST binding Step 1: User starts at any SP Saml_idp SP n

12 Hvad er der af hjælp? – til test eller udvikling
IdP SP OIOSAML.JAVA + BRS OIOSAML.NET + BRS SimpleSAMLphp Metadatachecker *) *) på vej

13 Det var SAML 2.0 – Hvad med ? Ekstern løsning ?

14 Identitetsbaseret Webservice
Traditionel løsning Fagsystem ID = Ekstern løsning ID = Log-in Den eksterne løsning ved kun med sikkerhed at anmodningen kommer fra fagsystemet. Den har ingen mulighed for at validere at anmodningen kommer fra en given bruger. Ekstern løsning Fagsystem Log-in ID = Anmodningen til den eksterne løsning sker med den givne brugers identitet. En betroet log-in-service (e.g. NemLog-in) står inde for at den givne bruger rent faktisk er logget ind – og den eksterne løsning har mulighed for at bede brugere bekræfte en anmodning via direkte dialog. ID-baseret løsning

15 OIO Identitetsbaseret Webservice 1.0
OIOIDWS 1.0 er en standard, der profilerer følgende Liberty Basic SOAP Binding ~ WSI Basic Security Profile med nødvendige udvidelser til at give interoperabilitet WS Trust 1.3 SAML 2.0 Token content & Bootstrap token

16 Roller Billetudsteder Token Issuer (STS) Serviceaftager
Web Service Consumer (WSC) STS WSC WSP Serviceudbyder Web Service Provider (WSP)

17 Etablering af tillid STS WSC WSP Serviceudbyderen stoler ikke nødvendigvis på Service-aftageren, men den stoler på Billetudstederen

18 ID-baseret forespørgsel
STS < > Stoler på: OK til: < > ID = Joe < > WSC Resultat WSP

19 Hvor kommer brugeren fra?
IdP STS Trust prior established WSP Token Validator SP WSC Fx..

20 Hvis nu transaktion er meget følsom….
IdP SP STS WSC WSP Token Validator Trust prior established Brugers browser redirectes til WSP, hvor brugeren direkte bekræfter transaktionen Request to Interact

21 Fordele ved OIOIDWS sammenlignet med mere traditionelle integrationsformer
Sikkerhedsmæssige og juridiske egenskaber Egenskab 1: Den kaldende applikation er autentificeret, og integriteten af kaldet er sikret Egenskab 2: En betroet tredjepart står inde for, at brugeren er logget på Egenskab 3: Data er krypterede under transport Egenskab 4: OIOIDWS Tokens sikrer at adgang gives begrænset Egenskab 5: Web servicen er autentificeret og integriteten af svaret er sikret Egenskab 6: Kald til web service kan logges som bevis Egenskab 7: Svar fra web service kan logges som bevis Egenskab 8: Samtykke fra borger Egenskab 9: Det er muligt at sætte et sikkerhedsniveau, der matcher det konkrete behov Kilde: Identitetsbaserede web services og personlige data, V0.8

22 Fælles infrastruktur til forskellige typer af webservices
Det er med OIOIDWS muligt at understøtte både webservices med ”almindelige” transaktioner såvel som webservices med følsomme transaktioner i flere niveauer. Samtidig skalerer det godt – Web Service Providers kan servicere nye Web Service Consumers uden at skulle etbalere direkte tillid til dem så længe som de benytter en STS som WSP’en stoler på

23 Hvor kommer profilerne i spil?
IdP STS Trust prior established OIO WS Trust profile OIO Bootstrap WSP Token Validator Liberty Basic SOAP binding SP WSC OIO SAML Profile for Identity Tokens

24 Status Interoperabilitetstest med COTS produkt ok for Java
Samarbejde med Digital Sundhed om tilretning af den gode webservice til interop med OIOIDWS Pilotintegrationer planlægges med Miljøportalen Profilerne kommer i OIO høring første halvår 2008 NemLog-in udvides med STS funktionalitet

25 Hvad er der af hjælp lige nu? – til test eller udvikling
WCS IdP+STS WSP OIOSAML-Trust.Java OIOIDWS.NET OIOIDWS PoC Alt dette er principielt i beta

26 Skift til 2 spor 11.15 Opsplitning
Dem der skKommandopromptal lave.Net hands-on går til Trifork, Margrethepladsen 4 - Resten bliver Udviklingsplanen for FOBS - v. Ellen Syberg Info om kurser i tilslutning - v. Thomas Gundel Opsætning af lokal test IdP - v. Thomas Gundel Introduktion til Digitaliser.dk v. Martin Høegh Mortensen 13.00 Alle går til Margretepladsen 4

27 Agenda – anden del 13.25 Opsplitning
Dem der skal lave Java hands-on bliver hos Trifork, Resten går tilbage til hotellet Introduktion til Digitaliser.dk v. Martin Høegh Mortensen Erfaring med integration af OIOSAML.NET I konkret produkt (Umbraco) - v. Thomas Ravnholt Microsoft's understøttelse af SAML v. Rene Løhde – Microsoft 14.45 Pause – Alle samles 15.00 Brugerstyringsmønstre – herunder sammenhængende log-in - v. Søren Peter Nielsen Plenum: Spørgsmål og svar; Hvor er barrierene? Indtil Fri erfaringsudveksling

28 Holder of Key

29 Etablering af tillid Issuing Authority certifikat ”Truster” Issuing Authority certifikat STS WSP Token Validator WSC WSC certifikat Serviceudbyderen stoler ikke nødvendigvis på Service-aftageren, men den stoler på Billetudstederen

30 Holder of Key WSC: Giv mig assertion for subject ”Joe” &
Issuing Authority certifikat ”Truster” Issuing Authority Certifikat ( ) STS WSP Token Validator ID = Joe WSC WSC certifikat WSC: Giv mig assertion for subject ”Joe” & Inkluder min nøgle i Subject Confirmation

31 Holder of Key Issuing Auth: Her er Assertion, som jeg har signeret
Issuing Authority certifikat ”Truster” Issuing Authority Certifikat ( ) STS Signed: Holder- of-Key Subject: Joe WSP Token Validator ID = Joe WSC WSC certifikat Issuing Auth: Her er Assertion, som jeg har signeret

32 Holder of Key Issuing Authority certifikat ”Truster” Issuing Authority Certifikat ( ) STS Signed: Signed: Holder- of-Key Subject: Joe Message content WSP Token Validator ID = Joe WSC WSC certifikat WSC: OK – jeg inkluderer SAML tokenet i SOAP Msg header. Jeg signer Msg med min nøgle og sender req

33 Holder of Key Issuing Authority certifikat ”Truster” Issuing Authority Certifikat ( ) STS Signed: Signed: Holder- of-Key Subject: Joe Message content WSP Token Validator ID = Joe WSC WSC certifikat WSP – Token Validator: OK – jeg stoler på SAML tokenet fordi det er signet af en issuing Auth jeg stoler på

34 Holder of Key Issuing Authority certifikat ”Truster” Issuing Authority Certifikat ( ) STS Signed: Signed: Holder- of-Key Subject: Joe Message content WSP Token Validator ID = Joe WSC WSC certifikat WSP – Token Validator: …og jeg kan se at der ikke er nogen som har fingeret med meddelesen fordi den er signeret med den nøgle, der er angivet i SAML-tokenets subject-confirmation