Versions Compared

Old Version 4

changes.mady.by.user Casper van der Harst

Saved on

compared with

New Version Current

changes.mady.by.user Casper van der Harst

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

10a.MedMij Registratie en elke PGO Server implementeren de use case UC Opvragen ZAL met de use case-implementatie UCI Opvragen ZAL, door middel van het bepaalde inzake het ZAL interface op GNL-, OCL- en ZAL-interface. Zij gebruiken hiertoe het betreffende stroomdiagram.
10b.PGO Server betrekt minstens elke vijftien minuten (900 seconden) de meest recente ZAL-implementatie van MedMij Registratie.
10c.PGO Server valideert elke nieuw verkregen ZAL-implementatie tegen het XML-schema van de Zorgaanbiederslijst. Dit XML-schema is een technische implementatie van het MedMij-metamodel.
11a.MedMij Registratie, Authorization Server en Notification Client implementeren de use case UC Opvragen OCL met de use case-implementatie UCI Opvragen OCL, door middel van het bepaalde inzake het OCL interface op GNL-, OCL- en ZAL-interface.  Zij gebruiken hiervoor het betreffende stroomdiagram.
11b.Authorization Server en Notification Client betrekken minstens elke vijftien minuten (900 seconden) de meest recente OCL-implementatie van MedMij Registratie.
11c.

Authorization Server en Notification Client valideren elke nieuwe verkregen OCL-implementatie tegen het XML-schema van de OAuth Client List. Dit XML-schema is een technische implementatie van het MedMij-metamodel.

12a.MedMij Registratie, PGO Server en Authorization Server implementeren de use case UC Opvragen GNL met de use case-implementatie UCI Opvragen GNL, door middel van het bepaalde inzake het GNL interface op GNL-, OCL- en ZAL-interface. Zij gebruiken hiervoor het betreffende stroomdiagram.
12b.PGO Server en Authorization Server betrekken minstens elke vijftien minuten (900 seconden) de meest recente GNL-implementatie van MedMij Registratie.
12c.PGO Server en Authorization Server valideren elke nieuwe verkregen GNL-implementatie tegen het XML-schema van de GNL. Dit XML-schema is een technische implementatie van het MedMij-metamodel.

Beveiliging

13.

In het gegevensverkeer voor UCI Verzamelen, UCI Delen, UCI Abonneren, UCI Notificeren, UCI Opvragen ZAL, UCI Opvragen OCL en UCI Opvragen GNL, maken betrokken rollen gebruik van de functies Versleuteling, Server Authentication en Server Authorization, volgens het bepaalde op de Netwerk-laag.

14.

De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKIoverheidPKI-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling.

Expand
titleToelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.1, 4.4.1.3, 4.4.1.4 en 4.4.1.5 in RFC 6819. De PKI-certificaten worden in deze release van het MedMij Afsprakenstelsel gebruik voor twee doelen op de Netwerklaag:authenticatie van servers en versleuteling, waarmee de vertrouwelijkheid en integriteit van de inhoud van het gegevensverkeer wordt geborgd.


15.

De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC6819:

beveiligingsmaatregelparagraaf in RFC6819gemitigeerde risico('s)
Clients should use an appropriate protocol, such as OpenID or SAML to implement user login. Both support audience restrictions on clients.4.4.1.134.4.1.13
All clients must indicate their client ids with every request to exchange an authorization "code" for an access token.

Keep access tokens in transient memory and limit grants.5.1.6
Keep access tokens in private memory.5.2.24.1.3
The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token.5.3.54.4.1.8
CSRF defense and the "state" parameter created with secure random codes should be deployed on the client side. The client should forward the authorization "code" to the authorization server only after both the CSRF token and the "state" parameter are validated.4.4.1.12


16.

De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC6819:

beveiligingsmaatregelparagraaf in RFC6819gemitigeerde risico('s)
Client applications should not collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g., the system browser.4.1.44.1.4
The client server may reload the target page of the redirect URI  in order to automatically clean up the browser cache.4.4.1.14.4.1.1
If the client authenticates the user, either through a single-sign-on protocol or through local authentication, the client should suspend the access by a user account if the number of invalid authorization "codes" submitted by this user exceeds a certain threshold.4.4.1.124.4.1.12
Client developers and end users can be educated to not follow untrusted URLs.4.4.1.84.4.1.8
For newer browsers, avoidance of iFrames during authorization can be enforced on the server side by using the X-FRAME-OPTIONS header. For older browsers, JavaScript frame-busting techniques can be used but may not be effective in all browsers.5.2.2.64.4.1.9
Explain the scope (resources and the permissions) the user is about to grant in an understandable way5.2.4.24.2.2


17.

De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conform RFC6819:

beveiligingsmaatregelparagraaf in RFC6819gemitigeerde risico('s)
Authorization servers should consider such attacks: Password Phishing by Counterfeit Authorization Server4.2.14.2.1
Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites.

Authorization servers should decide, based on an analysis of the risk associated with this threat, whether to detect and prevent this threat.4.4.1.10

4.4.1.10

The authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. 

The authorization server could make use of CAPTCHAs.

The authorization server should consider limiting the number of access tokens granted per user.4.4.1.114.4.1.11
The authorization server should send an error response to the client reporting an invalid authorization "code" and rate-limit or disallow connections from clients whose number of invalid requests exceeds a threshold.4.4.1.124.4.1.12
Given that all clients must indicate their client ids with every request to exchange an authorization "code" for an access token, the authorization server must validate whether the particular authorization "code" has been issued to the particular client.4.4.1.134.4.1.13
Best practices for credential storage protection should be employed.5.1.4.14.4.1.2
Enforce system security measures.5.1.4.1.14.3.2 en 4.4.1.2

Enforce standard SQL injection countermeasures.5.1.4.1.2
Store access token hashes only.5.1.4.1.3
The authorization server should enforce a one-time usage restriction.5.1.5.44.4.1.1
If an authorization server observes multiple attempts to redeem an authorization "code", the authorization server may want to revoke all tokens granted based on the authorization "code".5.2.1.1
Bind the authorization "code" to the redirect URI.5.2.4.54.4.1.3
the authorization server associates the authorization "code" with the redirect URI of a particular end-user authorization and validates this redirect URI with the redirect URI passed to the token's endpoint,4.4.1.7


18.

OAuth Client, OAuth Authorization Server en OAuth Resource Server implementeren de op deze respectievelijke rollen toepasselijke beveiligingsmaatregelen, volgens paragaaf 5.3 van RFC6750.

Expand
titleToelichting

Deze verantwoordelijkheid is opgenomen omdat met het bearer token informatie verkregen kan worden zonder dat nogmaals de identiteit wordt gecontroleerd. Daarom moeten maatregelen getroffen worden om te waarborgen dat het token alleen correct gebruikt kan worden.


...