Interfaces Autorisatie Server GTK
Metadata Interface
Feature | |
---|---|
Type | Service |
Versie | 1.0.0 |
Groep | GTK |
Gepubliceerd |
|
Delta | Initiële versie van feature. |
Use case | - |
Metadata
De metadata van de Autorisatie Server kan, conform RFC 8414, worden opgehaald op een well-known URL die kan worden geconstrueerd m.b.v. de <iss> claim uit het token (zie ook section-3.1 van RFC8414). De Authorization Server Metadata Response bevat de volgende attributen. Dit betekent dat bij een iss die gelijk is aan: https://FQDN/some-path-extension, de metadata kan worden verkregen bij: https://FQDN/.well-known/oauth-authorization-server/some-path-extension.
De metadata omvat de volgende attributen:
issuer
;token_endpoint
;jwks_uri
;response_types_supported
;signed_metadata
.
De response die wordt geretourneerd bevat daarnaast de volgende headers:
Cache-Control: must-revalidate, max-age=<max-age-metadata>
Pragma: no-cache
Een client mag verkregen metadata conform de Cache-Control
header directives, zoals beschreven in RFC 7234, cachen.
De waarde van max-age-metadata
is configureerbaar in de autorisatie server. Initiële waarde is 14400 seconden (4 uur).
JWKS
De public key waarmee de digitale handtekening kan worden gecontroleerd wordt als een JWK beschikbaar gesteld. De URL waarop de JWK Set kan worden opgevraagd (jwks_uri
) maakt deel uit van de AS metadata response. Iedere JSON Web Key (JWK) in de set, die beschikbaar wordt gesteld op de jwks_uri
, bevat een kid
parameter. De juiste JWK in de JWK Set wordt gevonden o.b.v. de waarde van het kid
attribuut in de header van de ontvangen JWT.
De response die wordt geretourneerd na een HTTP GET op de jwks_uri
bevat naast de JWK Set de volgende headers:
Cache-Control: must-revalidate, max-age=<max-age-jwks>
Pragma: no-cache
Een client mag verkregen JWK's conform de Cache-Control
header directives, zoals beschreven in RFC 7234, cachen.
De waarde van max-age-jwks
is configureerbaar in de autorisatie server. Initiële waarde is 14400 seconden (4 uur).
De JWK bevat de volgende attributen, waar de definitie van de attributen kan worden gevonden in RFC 7517 en RFC 7518:
"kty":"RSA"
"alg":"RS256"
"use":"sig"
"kid":"<the identifier of the key-pair used to sign this JWT>"
"x5c":"<de van toepassing zijnde keten van PKIX certificaten>"
"n":"<the modulus value for the RSA public key>"
"e":"<the exponent value for the RSA public key>"
TWIIN Assertion Interface
Feature | |
---|---|
Type | Service |
Versie | 1.0.1 |
Groep | GTK |
Gepubliceerd |
|
Delta | Verhelderd dat AS GTK de issuer is van assertion en client_assertion. |
Use case |
Feature | Versie | Dependency | Aanbieder | Afnemer |
---|---|---|---|---|
1.0.1 | * | * | ||
1.0.1 | AORTA-ID HTTP Header | * | * | |
1.0.1 | Verplicht >=4.* | * | ||
1.0.1 | * | - |
Inhoud en formaat van een issueAssertionsRequest
Middels deze interface kunnen een Twiin client_assertion en een Twiin assertion worden verkregen op basis van een AORTA access_token.
Een issueAssertionsRequest wordt op de volgende wijze verzonden:
POST [base endpointadres]/issueAssertionsRequest/v1
Bij het verzenden van een issueAssertionsRequest dienen de volgende HTTP headers te worden meegezonden:
Feature | AORTA-ID HTTP Header |
---|---|
Type | Subfeature |
Versie | 1.0.0 |
Groep | HTTP Headers |
Gepubliceerd |
|
Delta | Initiële versie van feature. |
AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>
Het initialRequestID attribuut bevat het ID van het allereerste request in de hele keten en dient te worden opgenomen in de logbestanden van alle partijen in de keten, zodat bij foutopsporing de verschillende logbestanden aan elkaar kunnen worden gerelateerd.
Het requestID is voor iedere request message uniek. In requests wordt deze gegenereerd door de client. Ook het requestID dient te worden opgenomen in de verschillende logbestanden, zodat altijd duidelijk is op welk bericht een log entry van toepassing is.
Content-Type: application/json; charset=utf-8
Het technische formaat van de HTTP body van een issueAssertionsRequest is:
{
"sourceTokenType": "",
"sourceToken": ""
}
Input parameters:
Name | Cardinality | Type | Toelichting |
sourceTokenType | 1..1 | String | Vaste waarde: “aorta-at+JWT”. |
sourceToken | 1..1 | Object | Een JWT-based AORTA access_token. |
Inhoud en formaat van een issueAssertionsResponse
Bij het verzenden van een issueAssertionsResponse dienen de volgende HTTP headers te worden meegezonden:
Content-Type: application/json; charset=utf-8
Het technische formaat van de HTTP body van een issueAssertionsResponse is:
{
"clientAssertion": "",
"assertion": "",
"scope": ""
}
Output parameters:
Name | Cardinality | Type | Toelichting |
clientAssertion | 1..1 | Object | Een client_assertion, zoals gespecificeerd in het Twiin afsprakenstelsel. De iss claim bevat de HTTPS-URL van Autorisatie Server GTK. |
assertion | 0..1 | Object | Een assertion, zoals gespecificeerd in het Twiin afsprakenstelsel. De iss claim bevat de HTTPS-URL van Autorisatie Server GTK. Aanwezig indien de hiervoor vereiste attributen aanwezig zijn in het sourceToken. |
scope | 0..1 | String | Slechts aanwezig indien een assertion wordt geretourneerd die geen authorization_base bevat. |
HTTP statuscodes
HTTP statuscodes die kunnen worden geretourneerd zijn opgenomen in onderstaande tabel.
Omdat bepaalde Confluence macro’s nog niet worden ondersteund in de publicatie omgeving, bevat de tabel, in de publicatieomgeving, ook informatie over de wijze waarop de betreffende interface wordt geïmplementeerd in de server component. De statuscodes die kunnen worden geretourneerd zijn opgenomen in de kolom “Uitkomst”. De overige informatie mag worden genegeerd.
Stap | Omschrijving | Uitkomst |
---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | Het systeem toetst of het verzoek voldoet aan de interface specificatie. | Ongeldig verzoek statuscode 400 Bad Request |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
3 | Het systeem controleert de geldigheid van het ontvangen sourceToken. | Ongeldig token statuscode 401 Unauthorized |
Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow. | ||
4 | Het systeem geneert, o.b.v. van de gegevens in het ontvangen sourceToken, een client_assertion en een assertion, conform het Twiin afsprakenstelsel. | |
5 <exit> | Het systeem retourneert een response naar de primaire actor. | Verwerking succesvol statuscode 200 OK |
TWIIN Token Interface
Feature | |
---|---|
Type | Service |
Versie | 1.0.1 |
Groep | GTK |
Gepubliceerd |
|
Delta | Initiële versie van feature: verwerken van een token request van een extern GTK. |
Use case |
Feature | Versie | Dependency | Aanbieder | Afnemer |
---|---|---|---|---|
1.0.1 | * | - | ||
1.0.1 | 2 | - | ||
1.0.1 | * | - | ||
1.0.1 | Verplicht >=4.* | - |
De TWIIN Token Interface is gespecificeerd in het TWIIN afsprakenstelsel, en is gebaseerd op het Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, en specifiek hierbinnen op het JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants.
Een tokenRequest wordt op de volgende wijze verzonden:
POST [base endpointadres]/token/v1