Komme igang med rekvirenttjenesten med HelseID
Innledning
Dette dokumentet beskriver hvordan rekvirenttjenesten i RF som støtter autentisering og signering med HelseID kan tas i bruk av rekvirentsystemer. Denne tjenesten heter RekvirentWebServiceV2.
Bestillinger
Det kreves en del oppsett for å kunne benytte testmiljøet til RekvirentWebServiceV2. Se også: Veiledning for tilkobling til testmiljø for rekvirentsystemer.
Bestille EDI-mailadresse
Bestille relevante oppføringer i adresseregisteret
Bestille aktører etter behov
Bestille registrering av aktører hos reseptformidleren
Nytt! Registere virksomhetens sertifikat hos reseptformidleren.
Nytt! Bestilling av tilgang til HelseID API-et. Tilgang til hdir:rf-rekvirent API hos HelseID selvbetjening.
Bestilling av tilgang til HelseID
Dette gjøres i HelseID selvbetjening ved å legge til tjenesten RF-Rekvirent med audience: hdir:rf-rekvirent under klientkonfigurasjonen. Søknaden om tilgang vil så behandles av Norsk helsenett.
Implementasjon
Implementasjonen er basert på at systemet allerede har implementert støtte for Rekvirent med personlig signatur/PKI. Hvis det utvikles ett helt nytt system kan man se bort ifra det som skal fjernes.
Hent ny WSDL fra /Rekvirent/RekvirentWebServiceV2
Funksjonalitet som skal fjernes:
Signering med rekvirentens personlige signatur skal ikke legges ved meldinger
Funksjonalitet som må innføres:
Rekvirentens HelseID access token (JWT - JSON Web Token) skal legges ved som HTTP Authorization header. JWT tokenet legges på http header i Authentication-feltet, merket som «DPoP».
Rekvirentens HelseID access token skal legges ved som vedlegg i hodemeldingen for M1 og M25_1 som beskrevet nedenfor.
Melding skal segles(signeres) med EPJ-leverandørens sertifikat. Segl skal være XMLDSig
Signering må gjøres med privatnøkkelen som samsvarer med sertifikat lastet opp til reseptformidleren. Det sertifikatet som er knyttet til CPA ID-en.
SOAP-melding skal krypteres med Web Service Security(WSS)
DPoP Proof skal genereres og legges ved i HTTP
DPoPheaderMelding sendes som POST request til nytt endepunkt
/Rekvirent/RekvirentWebServiceV2med https.
Se også: Signering av e-resept meldinger :
Legge til HelseID-vedlegg
For M1 og M25.1 meldinger skal HelseID access token vedlegges hodemeldingen.
Innholdet i Base64Container er base64 verdien av HelseID access token i JWS compact serialization format.
Dette formatet består av tre base64 kodede tekststrenger adskilt med punktum (.).
Forklaring fra JSON Web Token Structure:
JOSE Header: contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
JWS payload (set of claims): contains verifiable security statements, such as the identity of the user and the permissions they are allowed.
JWS signature: used to validate that the token is trustworthy and has not been tampered with. When you use a JWT, you must check its signature before storing and using it.
Eksempel: HelseID access token vedlegges hodemeldingen
NB! Namespace info er fjernet fra eksemplet.
|
<MsgHead>
...
<Document>
<RefDoc>
<MsgType DN="Vedlegg" V="A"/>
<MimeType>application/json</MimeType>
<Description>HelseID</Description>
<Content>
<Base64Container>..Base64Data...</Base64Container>
</Content>
</RefDoc>
</Document>
...
</MsgHead> |
Eksempel: Base64Data
Base64 verdien av HelseID access token.
ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklqYzROalkzUmprd1JFTXhNVUpHTURSQ1JEazBOamRFTVVZNU1USXdRelJCTkRNME1FSTBRMFlpTENKNE5YUWlPaUpsUjFwZmEwNTNVblozVXpsc1IyWlNMVkpKVFZOclRrRjBUVGdpTENKMGVYQWlPaUpoZEN0cWQzUWlmUS5leUpoZFdRaU9pSnVhRzQ2Y21WelpYQjBabTl5Yldsa2JHVnlaVzR0Y21WcmRtbHlaVzUwSWl3aWFYTnpJam9pYUhSMGNITTZMeTlvWld4elpXbGtMWE4wY3k1MFpYTjBMbTVvYmk1dWJ5SXNJbTVpWmlJNk1UY3pNVFV3T1RnME15d2lhV0YwSWpveE56TXhOVEE1T0RRekxDSmxlSEFpT2pFM016RTFNVEEwTkRNc0ltRjFkR2hmZEdsdFpTSTZNVGN6TVRVd09UZzBNaXdpYW5ScElqb2ljM1J5YVc1bklpd2lhR1ZzYzJWcFpEb3ZMMk5zWVdsdGN5OWpiR2xsYm5RdlkyeHBaVzUwWDI1aGJXVWlPaUpPVDFKVFN5QklSVXhUUlU1RlZGUWdVMFlnTFNCTFlYSmhkR1VnZEdWemRHVnlJQ2hMWVhKaGRHVWdRMGtnYTI5dVptbG5kWEpoYzJwdmJpa2lMQ0pqYkdsbGJuUmZZVzF5SWpvaWMzUnlhVzVuSWl3aWMyTnZjR1VpT2xzaWJtaHVPbkpsYzJWd2RHWnZjbTFwWkd4bGNtVnVMWEpsYTNacGNtVnVkQzl5Wld0MmFYSmxjbWx1WnlKZExDSm9aV3h6Wldsa09pOHZZMnhoYVcxekwyTnNhV1Z1ZEM5aGJYSWlPaUp6ZEhKcGJtY2lMQ0pvWld4elpXbGtPaTh2WTJ4aGFXMXpMMk5zYVdWdWRDOWpiR0ZwYlhNdmIzSm5ibkpmY0dGeVpXNTBJam9pTVRJek5EVTJOemc1SWl3aVkyeHBaVzUwWDJsa0lqb2laREZoT0dGaE5UQXRaVE0yWWkwMFpUa3pMV0kwWm1FdFlXWXpNV001TlRFM1kyRTVJaXdpYVdSd0lqb2ljM1J5YVc1bklpd2lhR1ZzYzJWcFpEb3ZMMk5zWVdsdGN5OXBaR1Z1ZEdsMGVTOXdhV1FpT2lJd056QXhOVGt3TURFek5DSXNJbWhsYkhObGFXUTZMeTlqYkdGcGJYTXZhV1JsYm5ScGRIa3ZjR2xrWDNCelpYVmtiMjU1YlNJNklqWm5jM0pZVldOQlozUlVOWG94ZHpkbllqZEthMEZwVTFRNU5VeHBhVWtyZFVsaEswTkZjSGN3ZFZrOUlpd2lhR1ZzYzJWcFpEb3ZMMk5zWVdsdGN5OXBaR1Z1ZEdsMGVTOXpaV04xY21sMGVWOXNaWFpsYkNJNklqUWlMQ0pvWld4elpXbGtPaTh2WTJ4aGFXMXpMMmxrWlc1MGFYUjVMMkZ6YzNWeVlXNWpaVjlzWlhabGJDSTZJbWhwWjJnaUxDSm9aV3h6Wldsa09pOHZZMnhoYVcxekwybGtaVzUwYVhSNUwyNWxkSGR2Y21zaU9pSnpkSEpwYm1jaUxDSnpkV0lpT2lJMlozTnlXRlZqUVdkMFZEVjZNWGMzWjJJM1NtdEJhVk5VT1RWTWFXbEpLM1ZKWVN0RFJYQjNNSFZaUFNJc0luTnBaQ0k2SW5OMGNtbHVaeUlzSW01aGJXVWlPaUp6ZEhKcGJtY2lMQ0ptWVcxcGJIbGZibUZ0WlNJNklrRkxSVXhGU1VVaUxDSm5hWFpsYmw5dVlXMWxJam9pUjB4VlVGTkxJaXdpYUdWc2MyVnBaRG92TDJOc1lXbHRjeTlvY0hJdmFIQnlYMjUxYldKbGNpSTZJakl5TWpJd01EQTRNU0lzSW1GdGNpSTZXeUp6ZEhKcGJtY2lYU3dpWTI1bUlqcDdJbXByZENJNkltdFphMnh6VDA5cWN5MXBWVXRpZUU0eFRuRmtTbkphVHpaMFpYWXdOemROTlVaVlZHNDBWbTh0TWtVaWZYMC5uc09kN2pZemZTRG9VdjZLMHB0a1hfSGtKYjlaRkhnVW9uVUZmbW42VE9mWlpPLWtnT2FyaUJGZEx5NEtuOGdSWEJjXzRKT0Z3MWpTbmswYjVydlZTRTVIZ1FRdVRFV2VzVDItUmd0VlNLdnJ4clEzYWpMSXptUTJmazRPd0dfZXFXTHBRVFotOE95b2FnOVIyM0tpc1FHT3VDdGZCQm5IbjZfQzJMWEhCamRERWg0XzhodVRxUy1HamszcGpQNVhoa0tYUlpmeVlWNFBzYUVnZVU4dE5RN3Z0M0RibFRYSGVacjMySElYY1UyWGdmVENtR2U1NFBmaEpnV2MtZ2t0b0k2RjhVWTNIOXVXbTNBZk12RTI0dmRPb0J3THpuU2p0aW1CME5wYnZXZWl3cV9ENkl3NHgzSEs3Q01XcWI0WldKUnZYN1FFcEpCMjdGS2p1c2trVzVoMjdZOFZfUGd3WUIxUURtcTczc0U5OWs3WFIxeHlxQkhvaEtFa0RtcWk5MVF4b2FiUDdMTy1qSGM2UlZHWjZaMkdBWW5LdzU3UG5sWE0zem1LeFY1TFQzRnlQV3hzeGwxYk1QekJ6QWRjQURFcG9JdnNEd2VNZm02ckg4clRla1VzRnZ4OUFVMVd4SEtHaER0SjdvNEdhQ09PVnpRV3E3eDdvLWVldjQxRw== |
Eksempel: Base64data dekodet
HelseID access token med 3 base64 kodede tekststrenger adskilt med punktum.
I eksemplet er linjeskift er lagt til før og etter punktum.
eyJhbGciOiJSUzI1NiIsImtpZCI6Ijc4NjY3RjkwREMxMUJGMDRCRDk0NjdEMUY5MTIwQzRBNDM0MEI0Q0YiLCJ4NXQiOiJlR1pfa053UnZ3UzlsR2ZSLVJJTVNrTkF0TTgiLCJ0eXAiOiJhdCtqd3QifQ
.
eyJhdWQiOiJuaG46cmVzZXB0Zm9ybWlkbGVyZW4tcmVrdmlyZW50IiwiaXNzIjoiaHR0cHM6Ly9oZWxzZWlkLXN0cy50ZXN0Lm5obi5ubyIsIm5iZiI6MTczMTUwOTg0MywiaWF0IjoxNzMxNTA5ODQzLCJleHAiOjE3MzE1MTA0NDMsImF1dGhfdGltZSI6MTczMTUwOTg0MiwianRpIjoic3RyaW5nIiwiaGVsc2VpZDovL2NsYWltcy9jbGllbnQvY2xpZW50X25hbWUiOiJOT1JTSyBIRUxTRU5FVFQgU0YgLSBLYXJhdGUgdGVzdGVyIChLYXJhdGUgQ0kga29uZmlndXJhc2pvbikiLCJjbGllbnRfYW1yIjoic3RyaW5nIiwic2NvcGUiOlsibmhuOnJlc2VwdGZvcm1pZGxlcmVuLXJla3ZpcmVudC9yZWt2aXJlcmluZyJdLCJoZWxzZWlkOi8vY2xhaW1zL2NsaWVudC9hbXIiOiJzdHJpbmciLCJoZWxzZWlkOi8vY2xhaW1zL2NsaWVudC9jbGFpbXMvb3JnbnJfcGFyZW50IjoiMTIzNDU2Nzg5IiwiY2xpZW50X2lkIjoiZDFhOGFhNTAtZTM2Yi00ZTkzLWI0ZmEtYWYzMWM5NTE3Y2E5IiwiaWRwIjoic3RyaW5nIiwiaGVsc2VpZDovL2NsYWltcy9pZGVudGl0eS9waWQiOiIwNzAxNTkwMDEzNCIsImhlbHNlaWQ6Ly9jbGFpbXMvaWRlbnRpdHkvcGlkX3BzZXVkb255bSI6IjZnc3JYVWNBZ3RUNXoxdzdnYjdKa0FpU1Q5NUxpaUkrdUlhK0NFcHcwdVk9IiwiaGVsc2VpZDovL2NsYWltcy9pZGVudGl0eS9zZWN1cml0eV9sZXZlbCI6IjQiLCJoZWxzZWlkOi8vY2xhaW1zL2lkZW50aXR5L2Fzc3VyYW5jZV9sZXZlbCI6ImhpZ2giLCJoZWxzZWlkOi8vY2xhaW1zL2lkZW50aXR5L25ldHdvcmsiOiJzdHJpbmciLCJzdWIiOiI2Z3NyWFVjQWd0VDV6MXc3Z2I3SmtBaVNUOTVMaWlJK3VJYStDRXB3MHVZPSIsInNpZCI6InN0cmluZyIsIm5hbWUiOiJzdHJpbmciLCJmYW1pbHlfbmFtZSI6IkFLRUxFSUUiLCJnaXZlbl9uYW1lIjoiR0xVUFNLIiwiaGVsc2VpZDovL2NsYWltcy9ocHIvaHByX251bWJlciI6IjIyMjIwMDA4MSIsImFtciI6WyJzdHJpbmciXSwiY25mIjp7ImprdCI6ImtZa2xzT09qcy1pVUtieE4xTnFkSnJaTzZ0ZXYwNzdNNUZVVG40Vm8tMkUifX0
.
nsOd7jYzfSDoUv6K0ptkX_HkJb9ZFHgUonUFfmn6TOfZZO-kgOariBFdLy4Kn8gRXBc_4JOFw1jSnk0b5rvVSE5HgQQuTEWesT2-RgtVSKvrxrQ3ajLIzmQ2fk4OwG_eqWLpQTZ-8Oyoag9R23KisQGOuCtfBBnHn6_C2LXHBjdDEh4_8huTqS-Gjk3pjP5XhkKXRZfyYV4PsaEgeU8tNQ7vt3DblTXHeZr32HIXcU2XgfTCmGe54PfhJgWc-gktoI6F8UY3H9uWm3AfMvE24vdOoBwLznSjtimB0NpbvWeiwq_D6Iw4x3HK7CMWqb4ZWJRvX7QEpJB27FKjuskkW5h27Y8V_PgwYB1QDmq73sE99k7XR1xyqBHohKEkDmqi91QxoabP7LO-jHc6RVGZ6Z2GAYnKw57PnlXM3zmKxV5LT3FyPWxsxl1bMPzBzAdcADEpoIvsDweMfm6rH8rTekUsFvx9AU1WxHKGhDtJ7o4GaCOOVzQWq7x7o-eev41G |
Eksempel: HelseID access token i klartekst.
HelseID access token dekodet i klartetkst. Kan dekodes med f.eks: JSON Web Tokens - jwt.io
{
"alg": "RS256",
"kid": "78667F90DC11BF04BD9467D1F9120C4A4340B4CF",
"x5t": "eGZ_kNwRvwS9lGfR-RIMSkNAtM8",
"typ": "at+jwt"
}
.
{
"aud": "nhn:reseptformidleren-rekvirent",
"iss": "https://helseid-sts.test.nhn.no",
"nbf": 1731509843,
"iat": 1731509843,
"exp": 1731510443,
"auth_time": 1731509842,
"jti": "string",
"helseid://claims/client/client_name": "NORSK HELSENETT SF - Karate tester (Karate CI konfigurasjon)",
"client_amr": "string",
"scope": [
"nhn:reseptformidleren-rekvirent/rekvirering"
],
"helseid://claims/client/amr": "string",
"helseid://claims/client/claims/orgnr_parent": "123456789",
"client_id": "d1a8aa50-e36b-4e93-b4fa-af31c9517ca9",
"idp": "string",
"helseid://claims/identity/pid": "07015900134",
"helseid://claims/identity/pid_pseudonym": "6gsrXUcAgtT5z1w7gb7JkAiST95LiiI+uIa+CEpw0uY=",
"helseid://claims/identity/security_level": "4",
"helseid://claims/identity/assurance_level": "high",
"helseid://claims/identity/network": "string",
"sub": "6gsrXUcAgtT5z1w7gb7JkAiST95LiiI+uIa+CEpw0uY=",
"sid": "string",
"name": "string",
"family_name": "AKELEIE",
"given_name": "GLUPSK",
"helseid://claims/hpr/hpr_number": "222200081",
"amr": [
"string"
],
"cnf": {
"jkt": "kYklsOOjs-iUKbxN1NqdJrZO6tev077M5FUTn4Vo-2E"
}
}
.
{
...signature
} |
FAQ
Meldingssignering
E-reseptmeldingen skal signeres med privatnøkkel tilhørende opplastet virksomhetssertifikat. Gyldig signering algoritme er rsa-sha256
E-reseptmeldinger er meldinger av typen M1, M5, M25.1 osv.
Q: Hvilket sertifikat skal benyttes for meldingssignering?
A: Du skal benytte ditt eget signerings sertifikat. Dette har KeyUsage = Non Repudiation
HTTP Request
HTTP request-en må ha Authorization header; verdien til header-en skal være DPoP {Access Token}. Det skal også sendes en DPoP header som inneholder DPoP beviset generert for den aktuelle request-en.
All HTTP trafikk skal krypteres med TLS 1.2 eller 1.3.
Web Service Security(WSS)
SOAP payload skal krypteres og signeres med Web Service Security(WSS).
For kryptering skal Reseptformidlerens krypteringsnøkkel benyttes. Denne kan hentes fra adresseregisteret.
Gyldige datakrypteringsalgoritmer er: aes256-cbc, aes256-gcm
Gyldige nøkkelkrypteringsalgoritmer er: rsa-oaep-mgf1p, rsa-oaep
For Signering skal innsenders sertifikat benyttes. Sertifikatet må være utstedt av en godkjent certificate Authority(Buypass/Comfides) og være gyldig.
Gyldige signeringsalgoritmer er: rsa-sha256, rsa-sha384, rsa-sha512
Dette er tilnærmet Basic256Sha256 AlgorithmSuite fra https://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826547 , men signatur algoritmen må overskrives ettersom det ikke er en definert Algorithm suite for rsa sha256.
Q: Hvilket sertifikat skal benyttes for WSS?
A: Du skal benytte reseptformidlerens krypterings sertifikat. Dette har KeyUsage = Digital Signature, Key Encipherment. Du skal også legge ved ditt eget krypterings sertifikat med samme KeyUsage
Meldinger i RekvirentWebServiceV2
Tabellen under viser hvilken meldingstyper og namespace som støttes av RekvirentWebServiceV2.
Eksempel på namespace i e.resept: "http://www.kith.no/xmlstds/eresept/m1/2013-10-08"
Melding | Svarmelding | Versjon (del av namespace) |
M1 | Apprec | 2013-10-08 |
M5 | M5.2 | 2013-04-16 |
M9.5 | M9.6 | 2021-02-01 |
M4.1 | M4.2 | 2006-10-06 |
M25.1 | Apprec | 2013-10-08 |
M27.1 | M27.2 | 2013-04-16 |
M9.11 | M9.12 | 2021-10-01 |
M9.7 | M9.8 | 2018-07-01 |
MV | Apprec | 2017-01-01 |
M9.21 | M9.22 | 2019-03-01 |