Bakgrund
Inom Sweden Connect finns sedan tidigare OIDC Metadata Requirements, som kompletterar de underliggande standarderna genom att ange vilka metadata som ska eller bör publiceras för olika protokollentiteter.
På motsvarande sätt finns behov av att inom Samordnad identitet och behörighet tydliggöra vilka metadata som krävs för OAuth Client, Authorization Server och Resource Server, inklusive gemensam metadata och hantering av protokollnycklar.
Som utgångspunkt används Sweden Connect – OIDC Metadata Requirements: Sweden Connect – OIDC Metadata Requirements
h1. Metadata requirements for OAuth 2.0 entities
...
1. Syfte
Denna specifikation anger krav på federationsmetadata för OAuth 2.0-protokollentiteter inom Samordnad identitet och behörighet.
Kraven syftar till att säkerställa att metadata som behövs för identifiering, teknisk tillit och interoperabilitet uttrycks på ett enhetligt sätt.
Specifikationen omfattar följande protokollentiteter:
oauth_clientoauth_authorization_serveroauth_resource
Kraven kompletterar OpenID Federation och Ena OAuth 2.0 Interoperability Profile. Den senare anger redan säkerhets- och interoperabilitetskrav för klienter, auktorisationsservrar och skyddade resurser.
...
2. Gemensamma krav
OpenID Federation definierar ett antal metadatafält som kan användas för samtliga protokollentiteter, bland annat organization_name, display_name, description, contacts, policy_uri, information_uri och organization_uri.
Föreslagen miniminivå:
...
| Metadata |
|---|
...
| Krav |
|---|
...
| Kommentar |
|---|
...
...
organization_identifier |
...
| REQUIRED |
...
| Identifierar den organisation som ansvarar för protokollentiteten. Ska följa OpenID Federation Organization Identifier Metadata Parameter. |
...
...
organization_name |
...
| REQUIRED |
...
| Läsbart namn på ansvarig organisation. |
...
...
display_name |
...
| REQUIRED |
...
| Läsbart namn som identifierar den tekniska komponenten |
...
| /protokollentiteten. |
...
...
contacts |
...
| RECOMMENDED |
...
| Kontaktuppgift för teknisk eller administrativ hantering av entiteten. |
...
...
description |
...
| OPTIONAL |
...
| Kort beskrivning av entiteten. |
...
...
information_uri |
...
| OPTIONAL |
...
| Länk till ytterligare information om entiteten. |
...
...
organization_uri |
...
| OPTIONAL |
...
| Länk till ansvarig organisation. |
...
Organisationsidentifieraren
...
bör vara central eftersom federationsplattformens tekniska ramverk redan anger att denna metadata används för att koppla en teknisk komponent till ansvarig organisation.
Organisationsidentifieraren bör följa en gemensam standard:
- Struktur enligt GLobal Unique Enterprise Identifier (GLUE)
...
- ietf.org/doc/draft-ietf-spice-glue-id/10/
- Denna ger möjlighet att stödja flera olika typer av identifierare samtidigt.
- ISO/IEC 6523
- internationell standard som definierar hur organisationer och delar av organisationer identifieras på ett entydigt sätt i elektronisk dataöverföring
- Rekommenderade format baserade på ovan standarder (vilka kan byggas ut efter behov):
- Svenskt organisationsnummer (ICD 0007)
- urn:glue:iso6523:0007:xxxxxxxxxx
- GLN-kod (ICD 0088)
- urn:glue:iso6523:0088:<gln-kod>
- Domänbaserad eDelivery Participant Identifier (ICD 0203)
- urn:glue:iso6523:0203:foretaget.se
- Svenskt organisationsnummer (ICD 0007)
...
3. Protokollnycklar
Om en protokollentitet använder asymmetriska nycklar i OAuth-protokollet ska dess publika protokollnycklar kunna hämtas från metadata.
Följande mekanismer definieras av OpenID Federation
...
:
jwksjwks_urisigned_jwks_uri
Dessa nycklar är separata från de federationsnycklar som används för att signera Entity Statements
...
Förslag: En entitet som behöver publicera protokollnycklar ska publicera dessa genom en av de mekanismer som tillåts av den tekniska profilen.
-
...
4. OAuth Client
Entity type: oauth_client.
OIDF tillåter metadata enligt OAuth Dynamic Client Registration samt gemensamma OpenID Federation-metadata.
Föreslagna krav:
...
| Metadata |
|---|
...
| Krav |
|---|
...
| Kommentar |
|---|
...
...
| Gemensamma metadata enligt avsnitt 2 |
...
| REQUIRED enligt ovan |
...
...
grant_types |
...
| REQUIRED |
...
| Anger vilka OAuth grant types klienten använder. |
...
...
token_endpoint_auth_method |
...
| REQUIRED |
...
| Anger hur klienten autentiserar sig mot |
...
| AS. |
...
...
token_endpoint_auth_signing_alg |
...
| CONDITIONAL |
...
Ska anges när vald autentiseringsmetod kräver signering, exempelvis private_key_jwt. |
...
...
jwks, jwks_uri eller signed_jwks_uri |
...
| CONDITIONAL |
...
| Krävs när klientens protokollnycklar behöver vara tillgängliga för andra parter. |
...
...
Scope bör tills vidare inte
...
göras till obligatorisk federationsmetadata. Vilka scopes en viss klient faktiskt är behörig att använda hör normalt till klientregistreringen hos
...
AS och bör hållas isär från beskrivningen av klientens federativa identitet.
...
5. OAuth Authorization Server
Entity type: oauth_authorization_server
...
OIDF anger att metadata enligt RFC 8414 och relevanta registrerade metadatafält får användas. issuer har dessutom ett uttryckligt OIDF-krav: värdet ska motsvara entitetens Federation Entity Identifier.
...
.
Föreslagna krav:
| Metadata | Krav | Kommentar |
|---|---|---|
| Gemensamma metadata enligt avsnitt 2 |
...
| REQUIRED enligt ovan |
...
...
issuer |
...
| REQUIRED |
...
| Ska motsvara Federation Entity Identifier. |
...
...
token_endpoint |
...
| REQUIRED |
...
| Endpoint för utfärdande av access tokens. |
...
...
grant_types_supported |
...
| REQUIRED |
...
| Grant types som |
...
| AS stöder. |
...
...
token_endpoint_auth_methods_supported |
...
| REQUIRED |
...
| Tillåtna autentiseringsmetoder för klienter. |
...
...
token_endpoint_auth_signing_alg_values_supported |
...
| CONDITIONAL |
...
| Ska anges om signerad klientautentisering används. |
...
...
scopes_supported |
...
| RECOMMENDED |
...
| Scope som |
...
| AS kan utfärda. |
...
...
jwks, jwks_uri eller signed_jwks_uri |
...
| REQUIRED när publika protokollnycklar behövs |
...
| Exempelvis för verifiering av signerade JWT. |
...
...
6. OAuth Protected Resource / Resource Server
Entity type: oauth_resource
...
OIDF anger att gemensamma metadata kan användas och att en deployment dessutom får använda Protected Resource Metadata enligt RFC 9728.
...
.
Föreslagna krav:
| Metadata | Krav | Kommentar |
|---|---|---|
| Gemensamma metadata enligt avsnitt 2 |
...
| REQUIRED enligt ovan |
...
...
resource |
...
| REQUIRED |
...
| Identifierar den skyddade resursen. |
...
...
authorization_servers |
...
| RECOMMENDED |
...
| Anger vilka Authorization Servers som kan användas för resursen. |
...
...
scopes_supported |
...
| RECOMMENDED |
...
| Anger vilka OAuth scopes resursen känner till. |
...
...
bearer_methods_supported |
...
| OPTIONAL |
...
| Om relevant för vald interoperabilitetsprofil. |
...
...
jwks, jwks_uri eller signed_jwks_uri |
...
| CONDITIONAL |
...
| Krävs endast om Resource Server har protokollnycklar som andra parter behöver verifiera. |
...
Exakt vilka RFC 9728-fält som ska vara REQUIRED bör avgöras tillsammans med användningsfallen och Ena OAuth-profilen
...
.
...
7. Metadata policy
De krav som lämpar sig för maskinell kontroll bör kunna uttryckas genom OpenID Federations metadata_policy.
OIDF anger uttryckligen att Trust Anchors och Intermediate Entities kan använda metadata policy för att säkerställa interoperabilitet eller följsamhet mot en säkerhetsprofil. Policyn är dessutom knuten till specifik entity type och enskilda metadatafält.
Exempel på krav som
...
sannolikt lämpar sig för sådan kontroll är:
- att obligatoriska metadata finns
- tillåtna
grant_types - tillåtna klientautentiseringsmetoder
- tillåtna algoritmer
...
h2. 8. Avgränsning
Federationsmetadata ska beskriva protokollentiteten och sådant som andra parter behöver kunna upptäcka och verifiera.
...