Authentifizierung und Autorisierung
Die Kommunikation im und mit dem Portalverbund Online-Gateway ist über OAuth2 gesichert. Im Rahmen des Portalverbundes wird hierfür Keycloak als Authentifizierungsserver verwendet. Um die Schnittstellen des Bereitstelldienstes des Portalverbundes abrufen zu können, muss eine Registrierung als Client beim Keycloak erfolgen. Ein Antrag zur Registrierung an Keycloak muss an dataportpvogsupport@dataport.de gestellt werden.
Nach erfolgreicher Registrierung am Keycloak erhält man eine Client ID und ein Client Secret mit welchen sich der entsprechende Client gegenüber Keycloak authentifizieren kann unter Verwendung des Client-Credentials-Flow (öffnet in neuem Tab). Nach der Authentifizierung erhält man ein Access Token (JWT Token) welches im Header der Anfrage als Bearer Token an den Bereitstelldienst mitgesendet werden muss. Damit ist der Zugriff auf den Bereitstelldienst möglich. Das Token hat nur eine begrenzte Lebensdauer und muss regelmäßig erneuert werden. Deshalb sollte für jeden Aufruf der Bereitstelldienstschnittstelle ein neues Token vom Keycloak abgerufen werden.
Exemplarischer Ablauf der Authentifizierung und Anfrage an den Bereitstelldienst
Es gibt zwei Umgebungen im PVOG (Stage und Produktion), die jeweils ihren eigenen Keycloak besitzen. Für jede Umgebung wird jeweils ein individueller Satz an Client-Credentials benötigt. Entsprechend werden Bearer Token aus einer Umgebung in den anderen Umgebungen nicht akzeptiert.
Im Folgenden wird der beispielhafte Ablauf einer manuellen Abfrage von Daten per curl aus der Stage-Umgebung des PVOG gezeigt.
Zunächst muss ein Access Token vom Keycloak abgerufen werden. Dazu werden Logindaten (client_id und client_secret) benötigt:
| Client ID | client_example |
|---|---|
| Client Secret | <CLIENT_SECRET> |
Und mit diesen Informationen kann dann ein Token beim Keycloak Server abgeholt werden:
curl -X POST \
'https://stage.pvog.fitko.net/auth/realms/pvog/protocol/openidconnect/
token' \
-H 'Accept: */*' \
-H 'Accept-Encoding: gzip, deflate' \
-H 'Cache-Control: no-cache' \
-H 'Connection: keep-alive' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'Host: stage.pvog.fitko.net' \
-d 'grant_type=client_credentials&client_id=client_example&client_secret=<CLIENT_SECRET>'
Keycloak validiert die Client Credentials und stellt ein Access Token aus, wenn diese in Ordnung sind. Ein Access Token sieht dann so aus:
{
"access_token":
"<ACCESS_TOKEN>",
"token_type": "bearer"
}
Mit diesem Access Token kann dann eine Abfrage an den Bereitstelldienst gestellt werden:
curl -X GET \'https://stage.pvog.fitko.net/bereitstelldienst/api/v3/verwaltungsobjekte/xzufi-2-3-1?index=0&ars=%25' \
-H 'Accept: */*' \
-H 'Accept-Encoding: gzip, deflate' \
-H 'Cache-Control: no-cache' \
-H 'Connection: keep-alive' \
-H 'Host: stage.pvog.fitko.net' \
-H 'Authorization: Bearer
<ACCESS_TOKEN>'
Beispielhafte Antwort des Bereitstelldienstes:
{
"naechsterIndex": 41221,
"vollstaendig": false,
"anzahlObjekte": 513,
"naechsteAnfrageUrl": "https://stage.pvog.fitko.net/bereitstelldienst/api/v3/verwaltungsobjekte/xzufi-2-3-1?index=41221&ars=%25",
"xzufiObjekte": "<?xml version=\"1.0\"
encoding=\"UTF8<xzufi:transfer.operation.050502 produktbezeichnung=\"PVOG\"
produkthersteller=\"Dataport AöR\" xmlns:gco=\"http://www.isotc211.org/2005/gco\"
xmlns:gmd=\"http://www.isotc211.org/2005/gmd\"
xmlns:gml=\"http://www.opengis.net/gml/3.2\"
xmlns:gsr=\"http://www.isotc211.org/2005/gsr\"
xmlns:gss=\"http://www.isotc211.org/2005/gss\"
xmlns:gts=\"http://www.isotc211.org/2005/gts\"
xmlns:xlink=\"http://www.w3.org/1999/xlink\"
xmlns:xml=\"http://www.w3.org/XML/1998/namespace\" xmlns:xoevcode=\"
http://xoev.de/schemata/code/1_0\" xmlns:xoevlc=\"
http://xoev.de/latinchars/1_1/datatypes\"
xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"
xmlns:xzufi=\"http://xoev.de/schemata/xzufi/2_3_1\"
xzufiVersion=\"2.3.1\">...</xzufi:transfer.operation.050502>"
}