Alternative konfigurasjoner av ADFS SSO

Fra Efaktor Wiki

Sammendrag

Denne siden tar for seg hvordan ADFS Single Sign On (SSO) til portaler som KS Læring og DIFI sin Virksomhetsplattformen fungerer og alternative konfigurasjoner for dette.


Oversikt

Skjematisk kan de forskjellige innloggingsalternativene beskrives slik:

Innloggingsalternativer



Logge inn via ID-porten

Når læringsplattformen benytter ID-porten for sikker autentisering, benyttes fødselsnummeret som brukernavn. Dette sikrer at en alltid har kun EN brukerkonto uavhengig av hvilken e-postadresse en måtte ha. Alle brukere med mulighet for autentisering via ID-porten vil derfor kunne logge inn på læringsplattformen. Innlogging via ID-porten sikrer også at brukerens kurshistorikk kan beholdes selv om en bytter arbeidssted. All brukerhistorikk følger fødselsnummeret.

En bruker som er autentisert via ID-porten har fått en "federerbar" innlogging på nivå 3. Det er i alt 4 nivåer og nettstedet som altinn.no og skatteetaten.no kan være eksempler på nivå 4-sikkerhet. Når du er innlogget med nivå 3, betyr det at du kan gå direkte til en rekke andre tjenester som benytter ID-porten på samme sikkerhetsnivå. OBS! for at det er KUN en gyldig ID-porten innlogging som tilbyr slik federering til andre nettsteder som også benytter ID-porten. Alle andre innloggingsmetoder, som er beskrevet her, gjelder bare for destinasjonen.

Første gang du logger inn på læringsplattformen via ID-porten vil alle dine brukerfelt (unntatt brukernavn) være tomme. Du blir da tatt inn i en kort veiviser som lar deg fylle inn fornavn, etternavn, e-post og evt. velge kommune/virksomhetslogo som skal benyttes i toppbanneret på kurssiden. (Unntaket fra dette er der hvor virksomheten har satt opp automatisk synkronisering av org-struktur med brukere.)Alternative_konfigurasjoner_av_ADFS_SSO#UNNTAK:

Logge inn via ADFS SSO

Når du logger inn via ADFS SSO fra kommunens/virksomhetens intranett vet datasystemet allerede hvem du er. Linken fører deg til f.eks. https://virksomhet1.weblogin.no hvor autentiseringen foregår mot virksomhetens ADFS-server. Er alt ok blir du umiddelbart videresendt til destinasjonen Virksomhetsplattformen eller KS Læring. Dersom det er noe galt/mangler med overføringen av brukerinformasjonen eller autentiseringen mot virksomhetens ADFS feiler av andre grunner, blir du i stedet videresendt til ID-porten for sikker innlogging der.


ADFS SSO Scenario 1:

Virksomhet 1 ønsker ADFS SSO til f.eks. Virksomhetsplattformen eller KS Læring.

Fødselsnummer ligger i AD som en skjult attributt.


ADFS SSO Scenario 2:

Virksomhet 1 ønsker ADFS SSO til f.eks. Virksomhetsplattformen eller KS Læring.

Fødselsnummer hentes fra et eget atributtlager på ADFS-serveren

  • virksomhet1.weblogin.no settes opp med simplesaml og utveksling av metadata.
  • ADFS-serveren har et eget attributtlager med mapping av ad-brukernavn og fødselsnummer.
  • ADFS-serveren kan levere fødselsnummer via en attributt (claim) som hentes fra eget attributtlager (Ikke AD) og kan dermed følge standard attributt-liste.
  • Løsningen testes i https://virksomhet1.weblogin.no/simplesaml først for å se at alle attributter blir oversendt.
  • https://virksomhet1.weblogin.no aktiveres med SAML og rutes for SSO mot DEV-miljøet.
  • Fem testbrukere logger inn og skal bli videresendt til DEV: https://difi.kursportal.net ferdig innlogget.
  • eFaktor sjekker at alle attributter er korrekt lagret i brukerens profil.
  • Deretter kobles over til PROD: https://virksomhetsplattformen.difi.no og prosessen gjentas med minst fem brukere.


OBS! for at ADFS-serveren må settes opp til å levere alle claims som attributter og ikke som oppslags-URL. Dette fordi rekursive oppslag av denne typen mot ADFS går via vanlig http.


ADFS SSO Scenario 3:

Virksomhet 1 ønsker ADFS SSO til f.eks. Virksomhetsplattformen eller KS Læring.

Fødselsnummeret ligger IKKE i AD og vil IKKE sendes med via SSO

Vi utnytter da at vi får alle brukerprofiler tilsendt via en nattlig synkroniseringsjobb basert på webservices. AD-brukernavnet blir da attributten som mapper mot korrekt konto på virksomhet1.weblogin.no før videresending og konvertering til fødselsnummer som brukernavn i Virksomhetsplattformen.

Hvordan gjøres integrasjonen?

eFaktor setter opp en login-server for virksomheten på formen: https://virksomhet1.weblogin.no og utveksler metadata med virksomhet1 sin adfs-server. Nødvendige attributter (kalles for "claims" i ADFS) er:

Obligatorisk attributt

  • brukernavn -> AD-brukernavnet


Standard attributter

  • fornavn -> Brukerens fornavn
  • etternavn -> Brukerens etternavn
  • email -> Brukerens e-postadresse
  • fodselsnr -> Brukerens fødselsnummer


Valgfrie attributter:

  • sted -> Brukerens stedstilhørighet
  • virksomhet -> Navn på virksomheten
  • mobil -> Brukerens mobilnummer


Er virkelig alle disse attributtene nødvendige??

Når brukeren skal inn på Virksomhetsplattformen eller KS Læring vi ha fødselsnummeret for å kunne mappe mot korrekt brukernavn der. Å benytte f.eks. e-post vil være altfor usikkert, da vi ikke har noen kontroll på gjeldende e-post på brukerkontoen som ligger i læringsplattformen. Vi ber om AD-brukernavnet for at vi skal ha en sikker referanse til hvilken bruker kilden (her: virksomhet1) sender data på.

AD-brukernavnet blir "liggende igjen" på login-serveren og sendes aldri til læringsplattformen. I stedet konverteres brukerkontoen på veien til læringsplattformen slik at fødselsnummeret nå blir brukernavnet, det opprettes en brukersesjon og brukeren får opp "Min startside" og er ferdig innlogget.

UNNTAK:

De fleste som ønsker ADFS SSO, ønsker også å synkronisere organisasjonsstrukturen med ledere og rapporttilganger, alle sine brukere og hvilke stillinger de har i egen virksomhet. Dette skjer via egen integrasjonsprogramvare, kalt "TARDIS" - og det er Bergen kommune som har vært pilot for å utvikle denne løsningen. Via kryptert webservice-forbindelse får vi regelmessig overført alle brukere med attributter, samt faktureringsinformasjon for org-enhetene. Da holder det at vi får en enkelt attributt (claim) fra AD og det er AD-brukernavnet.

Link for ADFS SSO

Hver virksomhet får i praksis en egen SSO-link som de skal klikke på for å komme til Virksomhetsplattformen eller KS Læring. Den er alltid på denne formen:

https://virksomhet1.weblogin.no/auth/saml/index.php

... hvor "virksomhet1" byttes ut med virksomhetens navn. Denne linken skjules vanligvis bak en knapp på intranett og den vanlige bruker ser aldri weblogin.no-portalene. De blir enten logget inn direkte til destinasjonen eller videresendt til ID-porten hvis det er noe galt med brukerkontoen.

Produksjonssetting og akseptanse

For at vi skal si oss ferdige med ADFS SSO må løsningen godkjennes. For alle scenarioene over følges samme prosedyre:

  • Vi kobler fra LAB til PROD: https://virksomhetsplattformen.difi.no og kunden tester med minst fem brukere.
  • Kunden gir tilbakemelding om ok.
  • eFaktor oversender akseptanseskjema for signering
  • eFaktor mottar signert akseptanse fra kunden og vi er ferdige.
  • Hvis ikke kunden signerer dokumentet innen en uke, rutes ADFS SSO tilbake til DEV, siden det er noe som gjør at de ikke signerer. Problemet løses og akseptanse fullføres.

Linker

ADFS SSO direktelinker fra intranett

Feilsøking når automatisk innlogging fra intranett (ADFS SSO) går galt

Tilbake til KS Læring

Tilbake til DIFI DIFI - På nett med læring