Denne vejlednings formål er at give en teknisk oversigt og vejledning for hvordan web-baserede løsninger på sundhedsområdet kan koble sig på SEB login-løsningen for borgere og medarbejdere. 

1. Indholdsfortegnelse 

 

2. Overblik over integrationsmuligheder 

SEB Sundheds-IdP er en national login-tjeneste, der kan benyttes af web-baserede applikationer på sundhedsområdet til at autentificere brugere på højt niveau via SAML protokollerne.  

Udover det, udsteder SEB digitale adgangsbilletter (tokens), der af web-baserede applikationer kan benyttes til at foretage viderekald til bagvedliggende tjenester på brugerens vegne. 

Slutteligt indeholder SEB et rolle/rettighedsmodul, der kan anvendes af brugerorganisationer til at administrere egne brugeres roller/rettigheder i SEB-tilsluttede webapplikationer centralt.  

SEB vil desuden kunne sættes op til at indgå i føderation med brugerorganisationers egne IdP’er og derved muliggøre fødereret brugerstyring. 

3. Tilslutningsguide til SEB IdP 

SEB er opdelt i en SEB IdP til borgerrettede løsninger og en SEB IdP til medarbejderrettede løsninger. 

SEB testmiljøet består af nedenstående IdP’er: 

 SEB produktionsmiljøet består af nedenstående IdP’er: 

Integration fra en webapplikation til SEB IdP’en (og derigennem med NemLog-in, samt regioners og kommuners lokale IdP’er) kan nedbrydes i følgende trin. 

 

Integration til SEB IDP 

  1. Indgåelse af formel tilslutningsaftale (På-vej). Tilslutningsaftale for adgang til SEB IdP sker ved henvendelse til SEB driftsforvaltningen: SEBDRIFT@sundhedsdata.dk
  2. Udveksling af SAML metadata med SEB IdP, så der kan etableres en tilslutning mellem IdP’en og webapplikationen 
  3. Etablering af login-funktionalitet på webapplikationen, således autentificeringen foregår gennem SEB IdP’en 
  4. Etablering af logout funktionalitet på webapplikationen, således der logges ud af både webapplikationen og SEB IdP’en 

3.1. OIOSAML bibliotekerne 

Der findes Java og .Net referenceimplementationer af henholdsvis OIOSAML2 (oiosaml2.java[1] og oiosaml2.net[2]) og OIOSAML3 (oiosaml3.java[3] og oiosaml3.net[4]) standarden, som med fordel kan benyttes til at implementere SAML protokollerne. Alle versioner er open source samt veldokumenterede, så benyttes Java eller .NET anbefales det at benytte en af disse biblioteker. Ellers bør der benyttes en standard SAML implementation, som så konfigureres til at overholde den benyttede OIOSAML Web SSO profileringen (OIOSAML2[5] og OIOSAML3[6]). 


[1] oiosaml2.java 2.1.2: https://www.digitaliser.dk/resource/6306532

[2] oiosaml2.net 2.0.6: https://www.digitaliser.dk/resource/6447464

[3] oiosaml3.java 3.2.0: https://www.digitaliser.dk/resource/6664259

[4] oiosaml3.net 3.0.1: https://www.digitaliser.dk/resource/6449669

[5] OIOSAML Web SSO profile 2.1.0: https://www.digitaliser.dk/resource/5833271

[6] OIOSAML Web SSO profile 3.0.3: https://www.digitaliser.dk/resource/6508977

3.2. Udveksling af SAML metadata 

For at integrere med SEB IdP’en skal der udveksles SAML metadata med den. SAML metadata er en kontrakt, som fortæller hvem webapplikationen (i rollen som SAML serviceprovider / SP) er, hvilke certifikater der benyttes, samt hvilket grænseflader der benyttes. 

Der skal konfigureres to filer med metadata, en fra IdP’en (fås fra SEB), og en fra SP’en. 

IdP metadata fortæller hvilke bindings (protokoller), samt hvilke certifikater som bruges til at kontrollere signering samt til at kryptere. OIOSAML implementationen ved ud fra dette metadata hvilke certifikater som skal bruges hvor. 

SAML 2.0 metadata for SEB IdP’erne kan hentes på hhv.: 

 

SP metadata skal konfigureres i SEB-IdP’en, og fortæller SEB-IdP’en hvilke bindings (protokoller), samt hvilke certifikater som kan bruges til at kontrollere signering samt til at kryptere. OIOSAML implementationen ved ud fra dette metadata hvilke certifikater som skal bruges hvor. 

Det to OIOSAML implementationer indeholder funktionalitet til generering af SP metadata, hvilket er nærmere beskrevet i dokumentationen af OIOSAML bibliotekerne. 

I OIOSAML er det kun redirect bindings som bruges. 

Metadata skal genereres af SP (webapplikationen) og skal udveksles med SEB der udstilles gennem en URL.  

3.2.1. Eksempel på SP Metatdata

Eksempel på SP metadata (certifikater er forkortet af med ’...’): 

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="demo.serviceprovider" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <md:SPSSODescriptor AuthnRequestsSigned="true"
        protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor use="signing">
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate> MIIFITCCBIqgAwIBAgIEQDa1...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
            Location="https://saml.serviceprovider.com:8080/saml/saml/LogoutServiceHTTPRedirect"
            ResponseLocation="https://saml.serviceprovider.com:8080/saml/saml/LogoutServiceHTTPRedirectResponse"/>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
            Location="https://saml.serviceprovider.com:8080/saml/saml/SAMLAssertionConsumer"
            index="0"/>
    </md:SPSSODescriptor>
</md:EntityDescriptor> 

3.2.2. For medarbejdervendte tilslutninger 

Udover udveksling af SAML metadata skal der for medarbejdervendte løsninger tages stilling til hvorvidt følgende oplysninger skal inkluderes i SEB tokenet: 

  • Sundhedsfaglige autorisationer 
  • Oplysninger om erhvervsmæssige tilknytninger til yderorganisationer 
  • SEB-administrerede roller/rettigheder for webapplikationen 
  • SEB-administrerede nationale roller 
  • Bootstraptoken, der via SOSI STS kan omvekles til SOSI IdKort. 

3.2.3. Koordinering af SEB-tilslutninger 

Kontakt SEB metadata koordinator funktionen i SEB systemforvaltningen på sebdrift@sundhedsdata.dk, der koordinerer indlæsning af SP-metadata samt etablering af konfiguration, der er relevant for medarbejdervendte løsninger med SEB’s leverandør. 

3.3. Etablering af login funktionalitet i webapplikationen 

Bruges OIOSAML reference-implementationerne skal der laves en loginknap, link eller lignende der rammer URL’en /saml/login/saml/* som er reference-implementationernes SAML dispatcher, som ser i IdP metadata, hvilken IdP loginside der skal rammes, og redirecter efterfølgende til denne URL. 

Herfra er det IdP’ens ansvar at brugeren autentificeres korrekt. Når dette er sket, returneres loginbilletten (et SAML token) fra IdP’en til SP’en, som så skal dekryptere og validere det og efterfølgende logge brugeren ind. 

Bemærk, at login-flowet ikke må implementeres i en separat iFrame, da NemLog-in ikke må frames. 

3.4. Etablering af logout funktionalitet i webapplikationen 

Bruges reference-implementationerne skal der ligeledes laves en logout knap, link eller lignende, der rammer URL’en /saml/logout. Igen ser reference-implementationernes dispatcher i IdP metadata, hvilket logout url der skal rammes, efterfølgende redirecter IdP’en til SP’en logout-url, hvorpå sessionen nedlægges, og brugeren dermed er logget ud. 

Bemærk, at logout derimod godt må foregå i en (usynlig) iFrame, men vær opmærksom på ikke at kalde logout direkte fra Javascript, idet SEB/NemLog-ins cookies da vil optræde som tredjeparts cookies, som i nogle browsere per default er slået fra og logout derfor vil fejle. 

3.5. FAQ til SEB-tilslutning 

Følgende er en liste af problemer der ofte forekommer ved tilslutning og hvad årsagen er: 

Jeg får “connection not found” fejl fra SEB når jeg forsøger at logge ind. 

Denne fejl forekommer, hvis der ikke er oprettet en forbindelse til jeres applikation på SEB. 

 

Tag fat i SEB Support og få dem til at hjælpe jer med at oprette en forbindelse til jeres applikation. 

Skal min applikation benytte HTTPS eller er HTTP ok? 

Jeres applikation skal benytte HTTPS. Føderationsprotokollerne kræver, at jeres applikation benytter HTTPS.  

Skal jeg købe et certifikat til føderationen eller kan jeg lave mit eget? 

Du behøver ikke købe et certifikat til føderationen. Det anbefales, at du selv generer certifikatet. 


3.6. Håndtering af SAML assertion 

Når brugeren er korrekt autentificeret via SEB/NemLog-in, vil en SAML assertion blive returneret til SP’en. SP’en skal dekryptere den indkommende SAML assertion og validere signatur, trust til signaturen og gyldighed i tid for assertionen – dette håndteres af standard SAML biblioteker og bør ikke kræve udvikling af applikationsspecifik kode.  

Mere information vedrørende indholdet i SAML assertions og den videre adgang til de nationale sundhedsservices findes her https://www.nspop.dk/display/KLMIDNLIN3. 

  • No labels