Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (9)
Destaque
Destaque (11)
Semelhante a A whistlestop tour of FHIR API authentication and authorization
Semelhante a A whistlestop tour of FHIR API authentication and authorization (20)
Último
Último (20)
A whistlestop tour of FHIR API authentication and authorization
- 1. A whistlestop tour of FHIR API authentication and authorization Dunmail Hodkinson HL7 UK
- 2. Authentication The process of identifying an individual Authorization Giving an individual access to operations and resources
- 3. FHIR standard • Does not include security • Provides guidance and suggestions • Includes supporting functionality https://www.hl7.org/fhir/security.html#authentication https://www.hl7.org/fhir/security.html#binding
- 4. PATTERNS
- 9. OAuth ‘An open protocol to allow secure authorization in a simple and standard way from web, mobile and desktop applications’ http://oauth.net/
- 10. SMART on FHIR ‘Medical apps that integrate into diverse EHRs at the point of care’ patient/*.read user/*.* patient/Observation.write http://docs.smarthealthit.org/authorization/scopes-and-launch-context/
- 11. JSON Web Token (JWT) ‘an open, industry standard RFC 7519 method for representing claims securely between two parties’ { iss: 'https://auth.example.net', sub: 'user@example.net', nbf: 1463059456166, exp: 1463064578213, iat: 1463059366160, aud: ['https://fhir.example.net'], jti: '5794b4f6-90bb-41a2-8e11-27ff4adb8880', } https://jwt.io/
- 12. JWT claims for FHIR { … fhir_scp: [ '*' ], fhir_act: [ 'read:Patient,Observation', ’$getRecord:Patient' ] } https://github.com/BlackPearSw/jwt-claims-fhir/blob/master/jwt-claims-fhir.md
- 14. Compartments ‘Each resource may belong to one or more logical compartments. A compartment is a logical grouping of resources which share a common property. … [They can] provide a definitional basis for applying access control to resources quickly.’ [base]/fhir/Patient/123/Condition https://www.hl7.org/fhir/compartments.html
- 15. Contract resource ‘A formal agreement between parties regarding the conduct of business, exchange of information or other matters’ https://www.hl7.org/fhir/contract.html
- 16. Consent resource ‘A record of a healthcare consumer’s privacy policy, which is in accordance with governing jurisdictional and organization privacy policies that grant or withhold consent.’ http://hl7-fhir.github.io/consent.html
Notas do Editor
- FHIR being adopted. Need to consider how we properly secure APIs. Terminology: Authentication vs Authorisation FHIR v2 https://www.hl7.org/fhir/security.html#authentication Authentication: Custom TLS-MA OAuth2 Authorisation: None Custom OAuth2 + OpenID Connect OAuth2 + OpenID (SMART tokens) jwt.io jwt claims for FHIR Apps - complex pattern Underlying support Compartments Contract resource Consent resource
- Authentication – none Authorisation – none Not recommended in production
- Example of a custom scheme Authentication: Server trusts client if the credentials (username:password) presented are accepted by the security provider Authorisation: Server allows client to access resources based on custom information provided by the security provider Quick and easy to implement. Can leverage existing authentication infrastructure e.g. LDAP
- Authentication: Server trusts clients who present valid X.509 certificate Authorisation: Server MAY access Good for B2B Client certificate management at scale can be hard
- Authentication: Server trusts clients that present a valid token from a trusted security provider Authorisation: Server allows client to access resources based on a claims within the token Good for individual level access OAuth2 - authentication
- De facto standard for bearer token 2 versions – OAuth, OAuth2 – FHIR recommends OAuth2
- Designed to allow apps to integrate to an EHR. Oauth2 authentication & access scopes Predates FHIR, so not a clear mapping between scopes and requests. Need custom code to differentiate operations e.g. is $bar a read operation or a write operation?
- Recommended by GDS Can be used in conjunction with OAuth2 Can be extended by adding additional
- Authentication: Server trusts clients that present a valid token from a trusted security provider Authorisation: Server allows client to access resources based on a claims within the token Good for individual level access OAuth2 - authentication
- Resource – not used directly for authentication and authorisation – may be used by an authorisation provider Could be used to record DSA Difficult to model individual patient consent
- Resource – not used directly for authentication and authorisation – may be used by an authorisation provider Could be used to record DSA Difficult to model individual patient consent
- Resource – not used directly for authentication and authorisation – may be used by an authorisation provider Could be used to represent individual patient consents