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

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

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

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 2.0 - 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 17.00 - Fri erfaringsudveksling

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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å

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

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

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

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

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 2.0 - 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 17.00 - Fri erfaringsudveksling

Holder of Key

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

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

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

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

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å

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