Användningsstöd

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:

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:

 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

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.

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"
  ]

Tidsstämplar i Token

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

exp

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

"exp" : 1528710504

iat

Tidpunkt då token utfärdades.

"iat" : 1528710204

auth_time

Tidpunkt då slutanvändaren autentiserade sig.

"auth_time" : 1528710199

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.

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.

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:

{
    "active": false
}

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

{
    "scope": "openid",
    "active": true,
    "exp": 1545218916,
    "token_type": "Bearer",
    "client_id": "https://e-tjänst.test"
}

{
    "active": true,
    "exp": 1545301716,
    "client_id": "https://e-tjänst.test"
}

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.

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.

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.

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.

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.

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.

Autentiseringsinformation

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

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.

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

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.