Kom godt igang med Single Sign-On

Ved brug af Single Sign-On (SSO) kan webredaktøren automatisk logge ind, når vedkommende er på jeres VPN og er logget ind på sin pc. Det betyder, at jeres webredaktører nemt og helt automatisk kan logge ind i jeres GoPublic-løsning.

Generel information

Når vi taler om Single Sign-On (fremover benævnt SSO), benyttes forskellige tekniske begreber. Nedenfor kan du finde disse begreber samt forklaringen af dem. 

Backoffice er der, hvor du kan konfigurere og redigere dine sites, brugere, styre brugerroller og adgang til sites samt meget andet.

Frontend er selve sitet, som alle kan tilgå og søge information på.

Users er brugere, der har adgang til backoffice.

Members er brugere, der har adgang til en begrænset side eller sektion i frontend. De har ikke adgang til backoffice.

Når du støder på begrebet 'brugere' kan der både være tale om users og members.

IdP er en forkortelse for 'Identity Provider'. Det er en service, der opbevarer, verificerer og administrerer identitet i jeres organisation.

Det kan for eksempel være:

  • Microsoft Active Directory
  • Google Workspace/Cloud Identity
  • Okta

For eksempel er 'MitID' en IdP for borgere i Danmark.

Hvilke data kræves?

I GoPublic kræves det, at jeres IdP konfigureres til at levere følgende data om accounts for at SSO virker:

  • UUID (Unique User Identifier)*
  • Brugernavn
  • Fornavn
  • Efternavn
  • E-mailadresse

Såfremt en del af ovenstående information mangler for nogen, der benytter login med SSO, vil personen blive mødt af en ekstra side, hvor den manglende information kan tilføjes. Dette vil kun ske ved første login med SSO.

Derudover skal der leveres rolleoplysninger fra jeres IdP, hvis I ønsker at benytte 'Role Matching'-funktionen.**

OBS! LÆS DETTE OMHYGGELIGT!

Vi opdaterer bruger-information med data leveret af IdP'en ved hvert login. 
Login er dog ikke altid det samme som, at nogen åbner en side på jeres løsning. Det betyder, at der afhængigt af konfigurationen kan være en forsinkelse mellem, hvornår brugeroplysninger ændres i jeres IdP, og hvornår de opdateres i GoPublic, hvilket kan påvirke brugerdata og -roller. Brugeren skal være logget ud for at udløse et login.

Vi udfører login på 4 måder:

  • Brugerinitieret logout fra backoffice ved brug af 'Logout'-knappen
  • IdP initieret logout ved hjælp ad SLO (Single Logout) funktionalitet (såfremt IdP understøtter dette scenarie og er kompatibelt med standarderne)
  • Tvungen logout, hvis brugerroller er ændret i GoPublic (f.eks. hvis nogen har ændret brugerroller i backoffice)
  • Maksimal sessionstid, hvorefter brugeren automatisk logges ud. Denne tid kan konfigureres, så den passer til jeres behov. Default er 7 dage.

* UUID kan ikke manuelt angives af brugeren. SSO login vil fejle, såfremt IdP ikke angiver UUID.
** Roller kan ikke manuelt angives af brugeren. Såfremt IdP'en ikke angiver rolleoplysninger og systemet er konfigureret til at benytte 'Role matching'-funktionen, vil den identitet ikke blive tildelt en rolle og som resultat heraf vil brugeren ikke være i stand til at logge ind i systemet før mindst én rolle er tildelt. Dette til trods for, at den pågældende bruger er blevet oprettet i backoffice. Dette gælder både for backoffice såvel som frontend.

Uddybning af spørgsmål

I dette afsnit kan I finde en uddybning af de spørgsmål vi har fremsendt til jer på mail. 

Vores løsning differentierer mellem to forskellige typer af brugere en person kan have:

  • Users er brugere, der har adgang til backoffice, men som også vil være i stand til at tilgå restriktede sider i frontend, såfremt brugeren har passende rettigheder. 
    Usere er ikke synlige under 'Edit member'-siden i frontend og i visse moduler, såsom 'Member directory' osv.
  • Members er brugere, der har adgang til restriktede sider i frontend. Members kan ikke logge ind i backoffice.

I nogle scenarier kan det ønskes at en person både har en user- og en member-bruger på samme tid.

GoPublic supporterer følgende Identity Providers:

  • MitID *
  • KOMBIT
  • Statens IT (SIT)
  • Microsoft Entra ID * (med undtagelse af Azure B2C eller Entra External ID)
  • ADFS
  • En hver anden udbyder, der er kompatibel med OIDC eller SAML standarder, selvom yderligere konfiguration kan være nødvendig

Hvis jeres udbyder ikke er på listen og I har spørgsmål til det, er I velkomne til at kontakte supporten.

* Se 'Yderligere information vedr. Identity Providers'.

Adgang til backoffice (for users) og frontend (for users og members) kan håndteres på to måder.

  1. Benyt Role Matching-funktionen sammen med SSO
    Jeres IdP-ansvarlige tildeler users og/eller members roller, som matcher de roller, der er defineret i GoPublic, via feltet 'SSO Role Name'. Her ligger rollestyringen hos jeres IdP-ansvarlige. Nye roller i jeres IdP-system, skal matches med roller defineret i GoPublic backoffice, ved brug af feltet 'SSO Role Name'.
    EKSEMPEL
    I har to roller defineret i jeres system: 'editor' og 'administrator'. Brugere i jeres system er tildelt disse roller.
    I ønsker, at rollerne automatisk bliver matchet i GoPublic. For at gøre det skal I: 

    1. Oprette nye roller, som I ønsker at have i GoPublic og konfigurere rettighederne. Lad os i dette eksempel antage, at vi opretter to roller, i backoffice af GoPublic, som vi kalder 'Editor_GoPublic' og 'Admin_GoPublic'
    2. Match de to GoPublic-roller med jeres IdP-roller ved at benytte feltet 'SSO Role Name' i backoffice.
      1. For 'Editor_GoPublic'-rollen skrives 'editor' i feltet
      2. For 'Admin_GoPublic'-rollen skrives 'administrator' i feltet
    3. Konfigurer jeres IdP til at sende information om, hvilke roller jeres brugere er tildelt i jeres system.
    4. Færdig! Ved login med SSO vil hver bruger blive tildelt den korrekte GoPublic-rolle baseret på data i jeres IdP-system.

  2. Via GoPublic
    En bruger med adgang til:

    1. 'Brugerroller' for brugere
    2. 'Memberroller' for members

skal manuelt tildele roller til brugere. Brugere oprettes uden roller, hvilket betyder, at de ikke vil kunne få adgang til systemet, før de er blevet tildelt en rolle. I har fuld kontrol over, hvem der gør hvad og hvem der kan se hvad. Enhver ændring på roller afspejles øjeblikkeligt på brugere, som er tildelt den ændrede rolle.

Der findes to forskellige login typer, når man benytter SSO.

  1. Login som valgmulighed
    Vælges denne type, vil der komme en knap ved siden af login-knappen på login-siden til backoffice. Her klikker man blot på SSO-knappen, og så bliver man logget ind.
  2. Automatisk login
    Hvis det laves som automatisk login, vil jeres brugere blive redirected og automatisk blive logget ind uden at lande på login-siden.

Yderligere information vedr. Identity Providers

Dette afsnit indeholder teknisk information vedr. nogle IdP'er og henvender sig til udviklere og/eller administratorer.

Microsoft Entra ID supporterer både OIDC and SAML protokollerne, men der er nogle yderligere overvejelser, man skal tage stilling til.

OIDC står for 'OpenID Connect'.

Det er en autentifikationsprotokol, der bygger oven på OAuth 2.0, og som bruges til at verificere en brugers identitet samt udveksle profiloplysninger på en sikker måde.

Kort forklaret:

  • OAuth 2.0 bruges til at give adgang til ressourcer (autorisation).

  • OpenID Connect (OIDC) udvider dette med identitet – altså hvem brugeren er.

Det betyder, at når en bruger logger ind via OIDC (fx med MitID eller Microsoft Entra ID), får applikationen bekræftet både:

  1. At brugeren er autentificeret, og

  2. Hvem brugeren er (via et ID-token med signeret information om brugerens identitet).

 

Begrænsninger

Microsoft Entra ID supporterer ikke alle specifikationer i OIDC (Open ID Connect), så nogle SLO scenarier vil ikke virke (log ud igangsat fra IdP).

 

Opsætning hos kunden

Ny app-registrering i Microsoft Entra ID:

For at opsætte den nye app, modtager I følgende information fra os: 

  • redirect uri
  • front channel logout uri

Efter oprettelse af ny 'Client' skal I:

1. Gå til 'API Permissions' og konfigurer permissions som på billedet nedenfor. Giv helst administratortilladelser til alle de viste permissions.

2. Gå til 'Token configuration' og konfigurer ID Token som vist på billedet nedenfor.


Claim'en 'groups' er valgfri og bruges kun i forbindelse med 'Role Matching'. Afhængigt af værdien i denne claim, skal I tilføje den passende værdi i 'SSO role name' i backoffice.

Såfremt I har ændringer til ovenstående to punkter, skal I kontakte vores support, så vores udviklere kan komme ind over.

 

Vi har brug for følgende fra jer: 

  • client id
  • client secret - I kan vælge udløbsdatoen på jeres client secret. Det er vigtigt, at I sørger for at give os besked, når den udløber, og dermed levere en ny til os.
  • tenant id
  • openid connect metadata document url
    • Findes under app-registreringen (den I opretter til os) -> endpoints button

Alternativt har vi brug for, at I inkluderer nogle yderligere claims i jeres ID tokens.

  • Krævet
    • Under 'App registration' skal I finde vores app
    • Gå til 'Token configuration'
    • Klik på 'Add optional claim'
    • Vælg 'preferred_username' for ID token
  • Valgfrit - hvis I ønsker mulighed for at benytte 'Role Matching'
    • Klik 'Add groups claims' og vælg, hvilken type gruppe I ønsker at videregive til os
    • Afhængigt af, hvad I vælger i 'Customize token properties by type' og jeres overordnede AD konfiguration, skal I indtaste de passende værdier i feltet 'SSO Role Name' i backoffice

 

Yderligere information vi forventer at modtage:  

1. Vi vil anmode brugeren om: openid profile email 

2. Vi mapper 'oid' claim med 'UUID'

3. Vi mapper 'preferred_username" med brugerens username 

4. Såfremt I ønsker, at vi benytter andre claims til UUID/username felter, har vi brug for, at I specificerer hvilke, og inkluderer dem i jeres ID token. 

SAML er en forkortelse for Security Assertion Markup Language. Det er en åben standard til Single Sign-On (SSO), som bruges til at overføre brugeridentitet og godkendelsesdata sikkert mellem forskellige systemer — typisk mellem en Identity Provider (IdP) (som fx. MitID) og en Service Provider (SP) (som fx et intranet, en app eller et website).

Når en bruger forsøger at logge ind på et system, der bruger SAML:

  1. Brugeren bliver sendt videre til IdP'en for at logge ind (f.eks. MitID).

  2. Når login er godkendt, sender IdP’en en SAML assertion (en digital signeret XML-besked), som bekræfter, at brugeren er autentificeret.

  3. SP'en modtager og stoler på denne besked og giver brugeren adgang uden at kræve endnu et login.

 

Fordele ved SAML

  • Single Sign-On (SSO): Brugeren logger kun ind én gang og får adgang til flere systemer.

  • Sikkerhed: Identiteten overføres via krypterede og signerede XML-beskeder.

  • Centraliseret styring: Login og brugerrettigheder håndteres ét sted (IdP).

  • Mindsker behovet for lokale brugerdatabaser: SP behøver ikke selv at gemme brugerkonti.

 

Begrænsninger

Visse indstillinger under 'Enterprise apps' i Microsoft Entra ID (som er nødvendige for at få dette til at virke), er muligvis begrænsede, afhængigt af, hvilken plan I benytter. GoPublic har ikke overblik over, hvad der er inkluderet eller ikke inkluderet i jeres plan, samt hvordan den eventuelt vil ændre sig. GoPublic benytter selv en gratis plan til test, og vi har succes med at konfigurere og benytte disse metoder.
'Test'-knappen, der benyttes til at teste SSO-forbindelsen i 'Single Sign-On'-menuen i 'Enterprise apps', vil ikke virke (og det er ok).

 

Opsætning hos kunden

Ny 'Enterprise app' in Microsoft Entra ID: 

For at opsætte det, vil I modtage en xml-fil, som I skal importere: 

  • Under 'Enterprise apps' skal I finde vores app
  • Gå til 'Single Sign-On' og vælg SAML
  • Klik 'Upload metadata file' og upload then fil I har modtaget fra os
  • Klik 'Edit' i 'Attributes & Claims' og konfigurer claims, så de matcher de viste nedenfor



Claim'en 'user.groups' er valgfri og bruges kun i forbindelse med 'Role Matching'. Afhængigt af værdien i denne claim, skal I tilføje den passende værdi i 'SSO role name' i backoffice.

Download 'Federation Metadata XML' og send url'en til 'App Federation Metadata Url' og send det til os.

Derudover skal I gøre en af følgende:

1. Gå til 'Users and Groups' og vælg users/groups, som skal have adgang til denne app og dermed vil få adgang til at logge ind via SSO

2. Gå til 'Properties' og opsæt som nedenfor

Ved ændringer til ovenstående, bedes I kontakte vores support, så vores udviklere kan komme ind over.

Begrænsninger

  • Når der benyttes MitID, kan 'Role Matching' ikke benyttes
  • MitID kan bruges af alle borgere i Danmark til at levere personens oplysninger til den service vedkommende forsøger at logge ind på (i dette tilfælde GoPublic). Dette betyder, at I skal have en metode, hvorpå I kan validere, om personen med det angivne CPR-nummer skal have adgang til løsningen. På nuværende tidspunkt, supporterer GoPublic kun en måde til at validere et CPR-nummer, hvilket kræver, at I hoster og vedligeholder en service, som vi kan sende en forespørgsel til.

Tekniske anmodningsoplysninger:

  • POST
  • API Key leveret i en header
    • header name kan justeres
  • Body: Json { "<cpr_key_name>:"<cpr_value>" }
    • cpr_key_name kan justeres
  • Forventet svar:
    • 200 OK - har adgang
    • Enhver anden kode - har ikke adgang
    • Response body ignoreres
  • Timeout: 30000 ms, ingen gentagne forsøg