Page History

...

• MitID Erhverv, hvor autentifikation af brugerne foregår i NemLog-in (enten med personligt MitID 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. MOCES3 understøttes som overgangsløsning for de brugerorganisationer, som tidsmæssigt ikke når at etablere egne lokale IdP'er.

Anvendelse af MitID Erhverv

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 er baseret på at der fås et omvekslingstoken (et såkaldt bootstraptoken) som i SOSI-STS'ens nye BST2SOSI snitflade kan veksles til et SOSI idkort, se STS - Guide til anvendere: Medarbejderomvekslinger.

1. Integration via SEB IdP (anbefalet), hvor SEB fungerer som proxy IdP for NemLog-in IdP'en, beriger OIOSAML tokenet med sundhedsattributter (autorisationer, nationale roller) og udsteder et (til SOSI-STS krypteret) bootstraptoken. Indholdet af det OIOSAML token, som fås af SEB IdP er specificeret som 'OIOSAML Assertion Profile for Healthcare' i OIOSAML Attribute Profiles for Healthcare v30.pdf
2. Integration via NemLog-in IdP og STS, hvor der fra NemLog-in IdP'en fås 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 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).