FAQ: Tilslutning af OIDC tjeneste i Unilogin

Tjenestekoden er et krav ifm. brug af GivAdgang til licensstyring. Tjenestekoden kan undlades hvis der ikke er behov for dette.

Læs mere om tjenestekoder i OIDC her:

• https://viden.stil.dk/display/OFFSKOLELOGIN/Tilslut+OIDC#TilslutOIDC-FeltspecifikationforoprettelseafOIDCtjeneste
• https://viden.stil.dk/display/OFFSKOLELOGIN/Tilslut+OIDC#TilslutOIDC-OIDCattributteriresponset

Tjenestekoden bruges sammen med udbydernummer til at tjekke om hvorvidt brugeren har licens til tjenesten.

Tjenestekoden er noget som tjenesteudbyderen selv definerer når en tjeneste oprettes i GivAdgang. Den valgte tjenestekode skal sendes med i metadata.

redirectUris er alle de URL'er, som en tjeneste har behov for at Unilogin kender, når der sendes requests/responses frem og tilbage i login- og logud-flows.

Behov og form kan variere. Som regel er der specificeret URL'er, såsom https://min-tjeneste.dk/login og https://min-tjeneste.dk/logout, så login og log ud kan gennemføres.

Der kan læses mere om redirectUris her: https://viden.stil.dk/display/OFFSKOLELOGIN/Tilslut+OIDC#TilslutOIDC-FeltspecifikationforoprettelseafOIDCtjeneste

rootUrl er en quality-of-life feature, så man kan ikke behøver at skrive domæne med til hvert endpoint i metadata. Dette er praktisk hvis det samme domæne bruges til alle endpoints.

Eksempel:

I stedet for følgende fuldt udskrevne URL'er:

{
  "redirectUris": [
    "https://tjeneste.domaene.dk/login",
    "https://tjeneste.domaene.dk/logout"
  ]
}

Så kan de skrives således:

{
  "rootUrl": "https://tjeneste.domaene.dk"
  "redirectUris": [
    "/login",
    "/logout"
  ]
}

Bemærk at dette:

• ikke vil fungere, hvis der er mere end et domæne, som skal kunne tilgås (heriblandt underdomæner).
  
• ikke er gældende for missingLicenseUrl, som specificeres andetsteds, og skal være en kvalificeret URL.

missingLicenseUrl er et felt som kan udfyldes ifm. licensstyring.

Hvis denne er specificeret, så videresendes brugere uden licens til denne URL efter login.

Hvis denne ikke er specificeret, så skal tjenesten selv håndtere afvisning af brugeren efter login.

webOrigins er et felt der er til for tillade CORS (Cross-Origin Resource Sharing). Dvs. deling af resourcer på tværs af domæner.

Her udfyldes URL'er I har behov for ifm. jeres tjeneste, som ikke direkte login relateret.

OBS: Vedlæg aldrig domæner I ikke stoler på i webOrigins. CORS er en almen og streng standard af sikkerhedsmæssige grunde.

Hvis du bliver bedt om at sende nyt metadata, så er det som regel pga. en eller flere af følgende:

• Der er fejl i metadata, og kan ikke uploades
  • Dette er ofte at slå fejl, såsom stavefejl i attributnavne eller overskydende kommaer
• Der er en eller flere URL'er i test-metadata som peger på et produktionsmiljø
• Der er en eller flere URL'er i produktions-metadata som peger på et testmiljø

Test og produktion holdes adskilt ved integration i Unilogin, og skal derfor reflektere sig i metadata.

publicClient attributten har betydning for om tjenesten skal bruge en secret ifm. login-flowet.

I den danske OIDC specifikation er minimumskravet at der bruges PKCE (Proof of Key Code Exchange). Specifikation er udgivet og vedligeholdt af Digitaliseringsstyrelsen.

Derudover er det et krav i specifikationen at en client er som confidential. Dvs. publicClient = false. Atributten står der udlukkende forud-udfyldt af praktiske årsager.

Rent teknisk forhindrer det at hele login-processen foregår i frontend, uden verificering af secret eller code-challenge på en tilhørende server.

Læs mere om den danske specifikation for OIDC her: https://digst.dk/media/24669/oio-oidc-profiles-v091.pdf

Læs mere om PKCE her: https://oauth.net/2/pkce/

Alle tjenester som har et idriftsat system i produktion, skal som minimum have et tilsvarende testsystem i det eksterne testmiljø (ET).

På ET kan man have et vilkårligt antal testsystemer til f.eks. lokal udvikling, preprod, osv.

Der er ingen omkostninger forbundet med bestilling af flere testsystemer

OpenID Connect (OIDC) er den moderne protokol som danner grundlag for bl.a. login, SSO og modtagelse af data om brugeren.

Det som adskiller OIDC (også kendt som "Fuld OIDC") og "OIDC Letvægtløsningen" er mængden af data som sendes tilbage til en tjeneste efter succesfuldt login.

Læs om hvilke claims der modtages med:

• Fuld OIDC: https://viden.stil.dk/display/OFFSKOLELOGIN/Tilslut+OIDC#TilslutOIDC-OIDCattributteriresponset
• OIDC Letvægtløsningen: https://viden.stil.dk/pages/viewpage.action?pageId=161059336#TilslutOIDC(Letv%C3%A6gtsl%C3%B8sning)-Eksempelp%C3%A5udfyldtmetadata

Hvilken OIDC tilslutningsform der skal vælges kommer an på hvor data der ønskes om brugeren ved login.

Hvis der ønskes UniID og andre henførbare data, så kræves en almindelig OIDC tilslutning (Fuld OIDC).

Hvis der ønskes en minimal loginløsning, hvor brugerens identitet ikke er relevant for løsningen, så kan den lille OIDC tilslutning (Letvægtløsningen) bruges. Her styres adgange via licenssystemer.

Valg af tilslutningsform til OIDC sker her: https://tilslutning.stil.dk/tilslutning/

Alle eksisterende aftaler om dataadgange oprettet via tilslutning.stil.dk udfases ikke, og de vil derfor fortsat kunne benyttes når jeres tjeneste skifter til OIDC-løsningen.

I skal blot anmode om adgang til enten Fuld OIDC eller Letvægtsløsningen når I nærmer jer produktion.

Data om brugerne som ikke findes som claims ifm. login hentes som nu via Webservices. 

Nej. Dataadgangen skal være godkendt for at kunne oprettes i produktion.

Tjenester kan oprettes i testmiljøet så snart at metadata er klar, og sendt i en supportsag.

Der kan oprettes en supportsag her: https://jira.stil.dk/servicedesk/customer/portal/7/create/72

Testbrugere til det eksterne testmiljø findes her: https://viden.stil.dk/display/OFFSKOLELOGIN/Testbrugere

Testbrugere med og uden licens findes her: https://viden.stil.dk/display/OFFSKOLELOGIN/Testbrugere#tab-Licensbrugere

Denne fejl betyder, som beskeden siger, at verificering af OIDC klienten i PKCE-flowet fejlede.

Denne kan opstå hvis den indsendte code_challenge ikke er blevet hashet korrekt baseret på den inputtede code_verifier. Dette leder til en code_challenge, som ikke kan verificeres af den oprindelige code_verifier, hvilket skaber fejlen.

Nedenstående resourcer anbefales, som hjælp til at debugge fejlen.

Eksempel på generering af code_challenge: https://viden.stil.dk/pages/viewpage.action?pageId=185470807#Implementeringaftjeneste-1.2.1Hvordangenerereskorrektcode_challengeogcodeverifier

Værktøj til at forstå hvordan code verifiers skal genereres: https://example-app.com/pkce

Læs mere om PKCE her: https://oauth.net/2/pkce/