Tjänsteleverantörens ansvar vid autentiseringen av en organisation som använder ett delat subsystem
I den här artikeln beskrivs vad tjänsteleverantören ska göra när en organisation som använder ett delat subsystem autentiseras.
Identifieringen av den som utnyttjar tjänsten sker på ett annat sätt i en situation där organisationen i fråga har anslutits till Informationsleden via en mellanaktörs anslutningsserver och ett delat subsystem. Ett delat subsystem består av flera organisationer som måste identifieras enligt en separat autentiseringsprocess. En beskrivning av hela autentiseringsprocessen finns i en separat stödartikel.
Autentisering med JWT är en exempellösning. Om tjänsteleverantören så önskar kan den genomföra autentiseringen också på något annat sätt.
I den här artikeln beskrivs autentiseringsprocessen med JWT-autentisering.
Tjänsteleverantören ansvarar för följande skeden i autentiseringsprocessen:
- Autentisera användaren.
- Bilda JWT eller annan motsvarande tagg om användaren har autentiserats.
- Skapa ett svarsmeddelande.
- Skicka svarsmeddelandet till den som utnyttjar tjänsten.
- Att anropa tjänsten med hjälp av JWT-autentisering eller något annat motsvarande autentiseringsförfarande.
Se till att du har gjort följande innan du inleder autentiseringsprocessen:
- Vi rekommenderar att ditt subsystem är tjänstespecifikt, det vill säga det finns endast en tjänst per subsystem. Din tjänst kan inte utnyttjas från det delade subsystemet om inte detta villkor uppfylls. Autentiseringen kan inte användas för att specificera vilken tjänst man vill använda, eftersom man i normala fall ger användarrättigheter per subsystem.
- Din tjänst har en API endpoint för autentisering av användarnamn för den som utnyttjar tjänsten.
- Du har skapat och skickat unika användarnamn med skyddad förbindelse till mellanaktören som representerar den som utnyttjar tjänsten.
Exempelgenomförande: Finlands miljöcentral som tjänsteleverantör Finlands miljöcentral (Syke) gör det möjligt att som tjänsteleverantör utnyttja sina tjänster via ett delat subsystem. Syke har genomfört en lösning som gör det möjligt för tjänsteleverantörens eget subsystem att innehålla mer än en tjänst. Syke har byggt upp en lösning för hantering av tjänstespecifik autentisering och användarbehörighet, med hjälp av vilken de som tjänsteleverantör kan identifiera användarens organisation och rättigheter tjänstespecifikt. Med hjälp av den tjänstespecifika identifierings - och åtkomstbehörighetshanteringen behöver tjänsteleverantörens subsystem inte vara tjänstespecifikt, utan det kan innehålla fler än en tjänst.
Tjänsteleverantörens ansvar i olika skeden av autentiseringsprocessen
1. Autentisera användaren
API endpoint som du lagt till i tjänsten validerar användarnamnen i förfrågningsmeddelandet.
För autentiseringen ska tjänsten tillhandahålla endpoint som validerar anroparens användarnamn och lösenord och återställer JWT-koden eller annan motsvarande tagg, med vilken användaren identifieras i tjänstens övriga endpoints.
SOAP-förfrågan
Om det är fråga om en SOAP-tjänst, bör du genomföra SOAP service med namnet "authenticate", som tar emot användarnamnet och lösenordet för den anropande organisationen i SOAP-meddelandet:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:id="http://x-road.eu/xsd/identifiers"
xmlns:xrd="http://x-road.eu/xsd/xroad.xsd"
xmlns:xrcl="http://localhost/application-auth"
xmlns:extsec="http://x-road.eu/xsd/security-token.xsd">
...
<SOAP-ENV:Body>
<xrcl:authenticate>
<xrcl:username>randomuser123</xrcl:username>
<xrcl:password>password123</xrcl:password>
</xrcl:authenticate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
REST-förfrågan
Genomför endpoint "POST /authenticate" i REST-tjänsten som tar emot användarnamnet och lösenordet för den anropande organisationen i headerdelen, till exempel:
POST /r1/FI/GOV/8765432-1/ProviderSubsystem/ProviderServiceCode/authenticate HTTP/1.1
...
X-Road-Represented-Party: MUN/0000000-0
Member-Username: randomuser123
Member-Password: password123
2. Bilda JWT eller annan motsvarande tagg om användaren har autentiserats
Generera JWT-koden eller annan motsvarande tagg om användarnamnen är giltiga. I annat fall får avsändaren ett felmeddelande. Observera att tjänsteleverantören ansvarar för valideringen av JWT-koden eller annan motsvarande tagg.
3. Skapa ett svarsmeddelande
1. Lägg till uppgifter som specificerar den organisation som utnyttjar tjänsten i svarsmeddelandets headerdel
SOAP-svar
Lägg till Third Party Representation -utvidgningen i svarsmeddelandets headerdel. Du hittar anvisningar för detta i NIIS dokumentationen (på engelska)Öppnas i ett nytt fönster..
REST-svar
Lägg till följande rad i svarsmeddelandets headerdel:
X-Road-Represented-Party: <Represented party member class/represented party member code>2. Lägg till JWT-koden eller annan motsvarande tagg som du genererar för den som utnyttjar tjänsten i svarsmeddelandets headerdel
SOAP-svar
Lägg till utvidgningen Security Token i svarsmeddelandets headerdel. Du hittar anvisningar för detta i NIIS dokumentationen (på engelska)Öppnas i ett nytt fönster..
REST-svar
Lägg till följande rad i svarsmeddelandets headerdel:
Authorization: Bearer <Token generated in the previous step if user is authenticated>4. Skicka svarsmeddelandet
Nedan ser du ett exempel på hur ett färdigt svarsmeddelande ska se ut när det innehåller alla nödvändiga rader. Observera att exempelvärdena är påhittade och ska ersättas med korrekta värden.
SOAP-svar
...
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:id="http://x-road.eu/xsd/identifiers"
xmlns:xrd="http://x-road.eu/xsd/xroad.xsd"
xmlns:extsec="http://x-road.eu/xsd/security-token.xsd"
xmlns:repr="http://x-road.eu/xsd/representation.xsd">
<SOAP-ENV:Header>
<xrd:client id:objectType="SUBSYSTEM">
<id:xRoadInstance>FI-TEST</id:xRoadInstance>
<id:memberClass>COM</id:memberClass>
<id:memberCode>1234567-8</id:memberCode>
<id:subsystemCode>TestClient</id:subsystemCode>
</xrd:client>
<xrd:service id:objectType="SERVICE">
<id:xRoadInstance>FI-TEST</id:xRoadInstance>
<id:memberClass>GOV</id:memberClass>
<id:memberCode>8765432-1</id:memberCode>
<id:subsystemCode>ProviderSubsystem</id:subsystemCode>
<id:serviceCode>ProviderServiceCode</id:serviceCode>
<id:serviceVersion>v1</id:serviceVersion>
</xrd:service>
<repr:representedParty>
<repr:partyClass>COM</repr:partyClass>
<repr:partyCode>MEMBER3</repr:partyCode>
</repr:representedParty>
<extsec:securityToken tokenType="urn:ietf:params:oauth:token-type:jwt">eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCJ9</extsec:securityToken>
</SOAP-ENV:Header>
</SOAP-ENV:Envelope>
REST-svar
HTTP/1.1 200
Content-Type: application/json; charset=utf-8
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCJ9
X-Road-Represented-Party: MUN/0000000-0
...
5. Att anropa tjänsten med hjälp av JWT-autentisering
När man anropar tjänstens övriga endpoints ska tjänsten validera anroparens JWT-token. Exempel på anropningar finns i kapitel 4 i dokumentet Mellanaktörens ansvar, som du hittar på denna länk.
Om JWT-valideringen får du också tilläggsuppgifter från referensgenomförandet som du hittar på denna länk (GitHub, på engelska)Öppnas i ett nytt fönster..
Tjänsteleverantören kan genomföra autentiseringen också genom annan autentisering än JWT-autentisering.