Revisionshistorik

Version

Datum

Författare

Kommentar

0.1

 

Upprättad
1.0

 

Grim SkarsgårdFastställd


 


1. Inledning

Inera IdP agerar OpenID Connect Provider (OP) i enlighet med [HEART.OAuth2] och [HEART.OIDC], med undantag för punkter listade i avsnittet om avsteg från arbetsunderlaget.

1.1. Notation

  • RP (Relying Party) - E-tjänst, motsvarar SP (Service Provider) i SAML.

2. Klientregistrering

För att kunna ansluta mot IdP:n behöver RP:n vara registrerad hos IdP:n. I samband med klientens registrering måste några beslut tas:

  • Vilka claims behöver klienten tillgång till. Se Attributstyrning OIDC.
  • Val av autentiseringsmetod: client_secret_basic, client_secret_jwt, client_secret_post, eller private_key_jwt [OpenID.Core].
    • Rekommenderad metod är private_key_jwt då metoden erbjuder en högre säkerhet än övriga alternativ och ger stöd för att kunna signera och/eller kryptera autentiseringsbegäran.
    • Vid val av private_key_jwt så ska ett certifikat exponeras till Idp:n vid registreringen. Exponeringen sker antingen genom att ett certifikat anges vid registreringen eller genom att en URL anges där man exponerar ett JWKSet [RFC 7517 Section 4], [exempel]. Se attributen jwks och jwks_uri i [OpenId.Registration].
    • För krav på RP:ns funktionscertifikat, se Guide till IdP.

3. Metadata för IdP (discovery endpoint)

Metadata för IdP:s OpenID Connect-funktionalitet finns tillgängligt enligt [OpenID.Discovery] på <IdP:s url>/oidc/.well-known/openid-configuration.


4. Giltighetstid

Varje typ av token har en egen giltighetstid. Dessa specificeras i Heart-profilerna.

TokenGiltighetstidReferens
id-token5 min[HEART.OIDC]
access-token1 h


[HEART.OAuth2]

refresh-token24 h


5. Användningsstöd

5.1. Autentisering

Förenklat flöde. Se detaljer i SAD IdP#OIDC

  1. RP skickar ett authentication request via användarens user-agent till IdP:s authorization_endpoint.
  2. IdP autentiserar användaren och returnerar en authorization code.
  3. RP byter in authorization code mot Access Token, ID Token och Refresh Token via IdP:s token_endpoint.

Exempel på Authentication Request:

Authentication Request
GET /oidc/authentication?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=s6BhdRkqt3
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
  Host: server.example.com


Exempel på Token Request:

Token Request
 POST /token HTTP/1.1
 Host: server.example.com
 Content-Type: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

 grant_type=authorization_code&
			code=SplxlOBeZQQYbYS6WxSbIA&
			redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

5.1.1. Ange vilka claims som RP efterfrågar

I förstudien är det ett SKALL krav att en RP skall ange vilka claims de ämnar nyttja och varför. Detta ligger till grund för konfiguration av RP i IdP'n. Enbart de claims som konfigurerats som giltiga kommer kunna hämtas av RP'n.

När en RP senare begär autentisering av en aktör kan önskade Scopes och/eller Claims specificeras.

Se Attributstyrning OIDC för mer information.

5.1.2. aud - Audience

aud-attributet returneras som en array med strängar, och innehåller:

  • client_id för klienten som gjorde autentiseringsbegäran
  • issuer_id för IdP
"aud": [
    "https://rp.e-tjanst.test:443",
    "https://idp.ineratest.org:443/oidc"
  ]


5.1.3. Tidsstämplar i Token

Se specifikation [OpenID.Core] för mer information.

5.1.3.1. exp

Giltighetstid som anger sista tidpunkt då token får processas.

"exp" : 1528710504

5.1.3.2. iat

Tidpunkt då token utfärdades.

"iat" : 1528710204

5.1.3.3. auth_time

Tidpunkt då slutanvändaren autentiserade sig.

"auth_time" : 1528710199

5.2. Hämta användardata från UserInfo Endpoint

[OpenID.Core]

  1. RP erhåller en Access Token efter autentisering av användaren hos IdP, enligt ovan.
  2. RP skickar denna Access Token via användarens user-agent till IdP:s userinfo_endpoint.
  3. IdP returnerar de användarattribut (claims) som angavs i autentiseringsbegäran att de skulle tillgängliggöras på UserInfo endpointen.

UserInfo endpointen kan användas för att få tillgång till användarattribut efter att ett ID Token har utgått, så länge motsvarande Access Token är giltigt.

5.3. Utloggning

SAD#Logga ut aktör

Utloggning sker enligt [OpenID.RPInitiatedLogout]

  1. RP skickar en logout request via användarens user-agent till IdP:s end_session_endpoint.
    1. Anropet kan innehålla ett fält id_token_hint med användarens ID Token.
    2. Om id_token_hint finns med så kan anropet också innehålla ett fält post_logout_redirect_uri med en adress till vilken IdP skall redirecta användarens user-agent efter utloggning. Värdet måste finnas registrerat i klientregistreringen för RP hos IdP.
    3. Anropet kan innehålla ett fält state som i så fall returneras av IdP som en query-parameter i omdirigeringen till RP efter utloggning.
  2. IdP invaliderar användarens SSO-session
    1. Om en ID Token skickades med i fältet id_token_hint i utloggningsbegäran så revokeras denna token och tillhörande Access Token och Refresh Token.
  3. Om fältet post_logout_redirect_uri  (och därmed också id_token_hint) finns med i utloggningsbegäran och kan valideras så dirigerar IdP om användarens user-agent till den angiva adressen.
  4. Om ingen post_logout_redirect_uri finns med eller om den inte kan valideras så skickas användaren till ett utloggningsmeddelande hos IdP.

5.4. Inspektera status för en token

Token introspection enligt [OAuth.Introspection]

  1. RP skickar en Access Token eller Refresh Token via användarens user-agent till IdP:s introspection_endpoint.
  2. IdP returnerar status för aktuell token.

Om aktuell token inte finns, har utgått eller är revokerad så returneras följande:

Introspection-svar för icke giltig token
{
    "active": false
}


Om aktuell token finns och är aktiv så returneras metadata om aktuell token enligt följande exempel:

Introspection-svar för giltig Access Token
{
    "scope": "openid",
    "active": true,
    "exp": 1545218916,
    "token_type": "Bearer",
    "client_id": "https://e-tjänst.test"
}
Introspection-svar för giltig Refresh Token
{
    "active": true,
    "exp": 1545301716,
    "client_id": "https://e-tjänst.test"
}


5.5. Revokera en utfärdad token

SAD#Revokera Tokens

Token revocation låter en RP invalidera en tidigare utfärdad token-uppsättning (sammanhörande Access Token, Refresh Token och ev. ID Token).

  1. RP skickar en Access Token eller Refresh Token via användarens user-agent till IdP:s revocation_endpoint.
  2. Om inskickad token ursprungligen var utfärdad till den RP som skickade in invalideringsbegäran så invaliderar IdP aktuell token och sammanhörande tokens.

Notera att användarens SSO-session hos IdP inte invalideras.


5.6. Biljettväxling av ett SAML-intyg till en OAuth2.0 Access Token (RFC7522)

SAD#Biljettväxling

Biljettväxling innebär att en RP som erhållit en SAML-biljett (utfärdad av Inera IdP eller av en annan av Inera IdP godkänd SAML-biljettutfärdare) kan växla in den mot en OAuth2.0 Access Token med motsvarande attribut.

Regelverk / förutsättningar för biljettväxling beskrivs i RFC7522.

5.6.1. Kärnflöde, biljettväxling

  1. RP har erhållit en SAML-biljett (Assertion) som den önskar växla mot en OAuth2.0 Access Token.
    1. SAML-biljetten måste vara utfärdad och signerad av IdP, alternativt av en av IdP betrodd intygsutfärdare (d.v.s. utfärdare vars SAML-metadata finns registrerat hos IdP).
    2. SAML-biljetten måste lista IdP:s "issuer"-id som ett <Audience>-element i <AudienceRestriction>, d.v.s. det id som IdP identifierar sig med i sitt OIDC-metadata.
    3. SAML-biljetten måste lista RP:s "client_id" som ett <Audience>-element i <AudienceRestriction>.
  2. RP skickar SAML-biljetten via användarens user-agent till IdP:s token_endpoint.
    1. RP autentiserar anropet som vanligt.
    2. Parametern "grant_type" sätts till "urn:ietf:params:oauth:grant-type:saml2-bearer".

    3. SAML-Assertionet skickas encodat med "base64url"-encoding enligt [OAuth.SAMLProfile].
  3. IdP returnerar en signerad OAuth2.0 Access Token som innehåller alla attribut som ingick i den inskickade SAML-biljetten.

5.6.2. Användningsexempel: En e-tjänst som använder SAML för användarautentisering har ett beroende till en annan e-tjänst som använder OAuth2.0 för åtkomstkontroll.


E-tjänst 1(Client, RP/SP) E-tjänst 1(Client, RP/SP) E-tjänst 2(RP/Resource Server) E-tjänst 2(RP/Resource Server) Inera IdP(SAML, OIDC, Oauth2) Inera IdP(SAML, OIDC, Oauth2) IDP 2(SAML) IDP 2(SAML) alt[autentisering via IDP 2] SAML AuthnRequest Autentisera användaren SAML-biljett alt[autentisering via Inera IdP] SAML AuthnRequest Autentisera användaren SAML-biljett Extrahera <Assertion> från SAML-biljetten alt[E-tjänst 1 utför biljettväxling] Biljettväxling med giltig Assertion Kontrollerar attbiljettväxling får ske Returnera Access Token samt Refresh Token API-anrop med Access Token alt[Vid behov] Kontrollera Access Tokenvia introspection_endpoint Status på Access Token Kontrollera behörighet utifrånattribut i Access Token Returnera svar på API-anrop alt[E-tjänst 2 utför biljettväxling] API-anrop med SAML Assertion Biljettväxling med giltig Assertion Kontrollerar attbiljettväxling får ske Returnera Access Token samt Refresh Token Kontrollera behörighet utifrånattribut i Access Token Returnera svar på API-anrop


5.7. Delegerad åtkomst i annat system via åtkomstintyg

IdP stödjer inte fullt ut delegerad åtkomst via åtkomstintyg enligt [Referensarkitektur - Identitet och åtkomst].

Det finns inget regelverk i IdP för att lägga till scopes i Access Token utöver de som IdP själv använder.

5.7.1. Delegerad tillgång till användarattribut via AccessToken och UserInfo-endpoint

En indirekt leverans av användarattribut till tredjepartstjänster kan åstadkommas m.h.a. UserInfo-endpointen. Tredjepartstjänsten kan sedan själv fatta beslut om åtkomst utifrån användarattributen.

Se också https://openid.net/specs/openid-connect-core-1_0.html#UserInfo.

Flödet ser ut som följer:

  1. RP skickar en inloggningsbegäran till IdP
    1. RP specificerar i sin claims request vilka användarattribut som skall tillhandahållas på UserInfo-endpointen, enligt Attributstyrning OIDC#claims.
  2. IdP autentiserar användaren
  3. RP får en code och hämtar en Access Token och en ID Token från IdP.
  4. RP begär åtkomst till ett API hos ett tredjepartssystem (TPS).
    1. RP inkluderar Access Token i sin begäran till TPS
    2. (Notera att ID Token aldrig skall spridas vidare av RP)
  5. TPS hämtar användarinformation från IdP genom att skicka Access Token till IdP på UserInfo-endpointen.
    1. IdP validerar att Access Token är giltig och levererar de användarattribut som specificerades av RP i steg 1.
    2. (Notera att TPS inte behöver identifiera sig gentemot – eller vara registrerad hos – IdP, utan behörigheten att hämta användarattributen ligger i innehavet av Access Token)
  6. TPS tar beslut om behörighet och åtkomst utifrån användarattributen från IdP.
  7. TPS svarar RP med begärd resurs eller information om att behörighet saknas.

Flödet kan vid behov också kombineras med tjänsteidentifiering, dvs att RP identifierar sig gentemot TPS m.h.a. t.ex. mTLS eller Client Credentials Grant.

6. Autentiseringsinformation

IdP använder samma klassificeringar för identifikationsmetoder och tillitsnivåer för OpenID Connect som i SAML-profilen.

6.1. Identifikationsmetod, amr

SSL/TLS Certificate-Based Client Authentication 

urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

Används för att autentisera aktören genom dess X.509 certifikat (t.ex. Efos eller SITHS).

Tillitsnivå: Beror på egenskaper i certifikatet. Detta hanteras i enlighet med Anslutningsguide till IdP.

6.2. Tillitsnivå, acr

Följande tillitsnivåer definieras av denna profil:

Tillitsnivå LoA1 
Låg tillit till en aktörs identitet. 
Identifikation: http://id.sambi.se/loa/loa1

Tillitsnivå LoA2 
Viss tillit till en aktörs identitet. 
Identifikation: http://id.sambi.se/loa/loa2

Tillitsnivå LoA3 
Hög tillit till en aktörs identitet. 
Identifikation: http://id.sambi.se/loa/loa3

Tillitsnivå LoA4 
Mycket hög tillit till en aktörs identitet. 
Identifikation: http://id.sambi.se/loa/loa4

7. Avsteg från arbetsunderlaget

  1. IdP tillhandahåller INTE Dynamic Client Registration (http://openid.net/specs/openid-heart-oauth2-1_0.html#DynamicRegistration).
    • Alla klienter måste registreras manuellt.
  2. IdP stödjer fler autentiseringsmetoder mot Token-endpointen än vad som är tillåtet enligt https://openid.net/specs/openid-heart-oauth2-1_0.html#rfc.section.2.1.2
    • client_secret_basic
    • client_secret_jwt
    • client_secret_post
    • private_key_jwt
  3. IdP stödjer INTE Implicit Flow (http://openid.net/specs/openid-heart-oauth2-1_0.html#rfc.section.3.1.1)
  4. Vid utloggning stödjs utöver id_token även access_token och refresh_token i id_token_hint.