Page History
...
- MitID Erhverv, hvor autentifikation af brugerne foregår i NemLog-in (enten med et personligt MitID identifikationsmiddel eller med et dedikeret MitID Erhverv identifikationsmiddel)
- Lokal IdP, hvor brugerorganisations selv står for autentifikation af brugerne i egen NSIS-anmeldt IdP og med egne identifikationsmidler (fx smartcards)
- MOCES3 certifikater, hvor autentifikation som hidtil foregår med samme flow i SOSI-STS foregår efter samme flow som med nuværende MOCES2. MOCES3 understøttes som overgangsløsning for de brugerorganisationer, som tidsmæssigt ikke når at etablere egne lokale IdP'er.
...
MitID Erhverv kan i princippet anvendes i andre MitID brokere end NemLog-in, men for at kunne understøtte udstedelse af SOSI idkort skal autentifikation af brugerne foregå i NemLog-in. Der er to integrationsmuligheder for at kunne få udstedt SOSI idkort - begge mønstre integrationer er baseret på at der fås modtages et omvekslingstoken (et såkaldt bootstraptoken), som i SOSI-STS'ens nye BST2SOSI snitflade kan veksles til et SOSI idkort.
- Integration via SEB IdP (anbefalet), hvor SEB fungerer som proxy IdP for NemLog-in IdP'en , og beriger OIOSAML tokenet med sundhedsattributter (autorisationer, nationale roller) og udsteder , samt med et (til SOSI-STS krypteret) bootstraptoken. Indholdet af det OIOSAML token, som fås modtages af SEB IdP er specificeret som overholder 'OIOSAML Assertion Profile for Healthcare' i OIOSAML Attribute Profiles for Healthcare v30.pdf.
- Integration via NemLog-in IdP og STS, hvor der fra NemLog-in IdP'en fås modtages et fællesoffentligt bootstraptoken, som ved NemLog-in STS'en via et WS-Trust SOAP kald veksles til et nyt krypteret (sundheds) bootstraptoken, som til sidst kan veksles til et SOSI idkort.
Begge mønstre integetrationsmuligheder er baseret på SAML WebSSO protokollen til kommunikation med henholdsvis SEB IdP'en eller NemLog-in IdP'en og kræver dermed, at log-in fra fagsystemet foregår i en browser (eller alternativt i en indlejret browserkomponent).
...
Store brugerorganisationer som har valgt at implementere egen NSIS-anmeldt IdP kan registreres som trusted udsteder af bootstraptokens i til SOSI-STS. Bootstraptokens udstedt af egen IdP skal overholde OIO Healthcare Bootstrap Token Profile v10.pdf. Bemærk, at kommunikation mellem fagsystem og Lokal IdP ikke nødvendigvis behøver at være browserbaseret, men er overladt til lokalt implementering.
...
Udover at SOSI-Gateway kan understøtte oprettelse af idkort på baggrund af MOCES3 certifikater er SOSI-Gateway blevet udvidet med en ny 'createIdCardFromBST' snitflade, der kan oprette SOSI idkort i SOSI-Gateway'ens cache ud fra et bootstraptoken, som STS'en truster (fx fra en lokal IdP eller SEB IdP'en). Snitfladen Input til snitfladen 'createIdCardFromBST' tager er samme WS-Trust request som input som anvendes i kald til SOSI-STS'ens BST2SOSI, se også SOSI-GW - Guide til anvendere.
...
Webapplikationer der benytter enten NemLog-in IdP'en eller SEB IdP'en til autentifikation af brugerne vil fortsæt kunne anvende de to IdP'er. I første omgang med de nuværende OIOSAML2 baserede protokoller/attributter, som skal migreres til OIOSAML3 baserede protokoller/attributter - for SEB-tilslutninger dog først på lidt længere sigt. Bemærk, at nuværende OIOSAML2SOSI snitflade på SOSI-STS (som kan anvendes til at omveksle en OIOSAML2 assertion fra NemLog-in IdP'en) ikke opdateres til OIOSAML3. I det omfang, der fra webapplikationen er behov for at kunne kalde videre via DGWS, bør applikationen i stedet omveksle det bootstraptoken, som modtages fra henholdsvis NemLog-in IdP'en eller SEB IdP'en, til et SOSI idkort som beskrevet i ovenstående.
Derimod vil nye tilslutninger til SEB IdP'en skulle basere sig på OIOSAML3, konkret er det 'OIOSAML Assertion Profile for Healthcare' fra OIOSAML Attribute Profiles for Healthcare v30.pdf som beskriver attributsættet, som webløsninger kan modtage.
...