O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

de

Security in FHIR with OAuth by Grahame Grieve Slide 1 Security in FHIR with OAuth by Grahame Grieve Slide 2 Security in FHIR with OAuth by Grahame Grieve Slide 3 Security in FHIR with OAuth by Grahame Grieve Slide 4 Security in FHIR with OAuth by Grahame Grieve Slide 5 Security in FHIR with OAuth by Grahame Grieve Slide 6 Security in FHIR with OAuth by Grahame Grieve Slide 7 Security in FHIR with OAuth by Grahame Grieve Slide 8 Security in FHIR with OAuth by Grahame Grieve Slide 9 Security in FHIR with OAuth by Grahame Grieve Slide 10 Security in FHIR with OAuth by Grahame Grieve Slide 11 Security in FHIR with OAuth by Grahame Grieve Slide 12 Security in FHIR with OAuth by Grahame Grieve Slide 13 Security in FHIR with OAuth by Grahame Grieve Slide 14 Security in FHIR with OAuth by Grahame Grieve Slide 15 Security in FHIR with OAuth by Grahame Grieve Slide 16 Security in FHIR with OAuth by Grahame Grieve Slide 17 Security in FHIR with OAuth by Grahame Grieve Slide 18 Security in FHIR with OAuth by Grahame Grieve Slide 19 Security in FHIR with OAuth by Grahame Grieve Slide 20 Security in FHIR with OAuth by Grahame Grieve Slide 21 Security in FHIR with OAuth by Grahame Grieve Slide 22 Security in FHIR with OAuth by Grahame Grieve Slide 23 Security in FHIR with OAuth by Grahame Grieve Slide 24 Security in FHIR with OAuth by Grahame Grieve Slide 25 Security in FHIR with OAuth by Grahame Grieve Slide 26 Security in FHIR with OAuth by Grahame Grieve Slide 27 Security in FHIR with OAuth by Grahame Grieve Slide 28 Security in FHIR with OAuth by Grahame Grieve Slide 29 Security in FHIR with OAuth by Grahame Grieve Slide 30 Security in FHIR with OAuth by Grahame Grieve Slide 31 Security in FHIR with OAuth by Grahame Grieve Slide 32 Security in FHIR with OAuth by Grahame Grieve Slide 33 Security in FHIR with OAuth by Grahame Grieve Slide 34 Security in FHIR with OAuth by Grahame Grieve Slide 35 Security in FHIR with OAuth by Grahame Grieve Slide 36 Security in FHIR with OAuth by Grahame Grieve Slide 37 Security in FHIR with OAuth by Grahame Grieve Slide 38 Security in FHIR with OAuth by Grahame Grieve Slide 39 Security in FHIR with OAuth by Grahame Grieve Slide 40 Security in FHIR with OAuth by Grahame Grieve Slide 41 Security in FHIR with OAuth by Grahame Grieve Slide 42
Próximos SlideShares
FHIR architecture overview for non-programmers by René Spronk
Avançar
Transfira para ler offline e ver em ecrã inteiro.

6 gostaram

Compartilhar

Baixar para ler offline

Security in FHIR with OAuth by Grahame Grieve

Baixar para ler offline

Security in FHIR with OAuth by Grahame Grieve

Security in FHIR with OAuth by Grahame Grieve

  1. 1. Securing FHIR with OAuth Grahame Grieve FHIR Developer Days November 25, 2014 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  2. 2. Overview  Overview of Security Landscape for FHIR  About OAuth and issues  I’ll take questions as we go 2 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  3. 3. Overview  Securing an API is both painful and necessary  You want to secure it just enough  The threat model is changing rapidly  There’s no “get it right up front”  There’s a rapid response arrangement with regard to security in FHIR 3 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  4. 4. Overview  Communications Security  Authentication  Authorization/Access Control  Audit  Digital Signatures  Attachments / Narrative  Security labels 4 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  5. 5. Communications  Current Practice  secure public, insecure ‘private’ communications  FHIR Recommends always using SSL (/ TLS)  Only TLS 1.2 recommended now, but not supported on some platforms  Need to use Client Certificates to get meaningful security (anti-Man in the Middle)  Post-Snowden, this should get easier 5 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  6. 6. Auth vs Auth  Authentication  Who is at the other end (machine, software, human)?  Authorization  What is the (process) allowed to do?  Confusing for many people, because you generally have to do the first to decide the second 6 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  7. 7. Authentication  Who is the other end of the communication channel?  Shared Secret (e.g. password)  Token (e.g. client certificate)  Biometrics (if user physically available)  There are lots of reasons why different solutions are appropriate  FHIR does not fix to any particular one 7 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  8. 8. Authorization  In FHIR terms, what resources can the user see / change?  What happens when they try to access something they can’t see? Change something they can’t change? 8 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  9. 9. Authorization 9 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  10. 10. Authorization  In FHIR terms, what resources can the user see / change?  What happens when they try to access something they can’t see? Change something they can’t change?  Difficult: the user can see part of the resource  More difficult: the narrative is frequently denormalised 10 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  11. 11. Audit  SecurityEvent resource records events  Based on ATNA (IHE spec)  The RESTful API allows create, but not update or delete (= ATNA)  Search / read allows users to process an event log (functionality beyond ATNA) 11 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  12. 12. Audit 12 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  13. 13. Digital Signatures  Allow for testing about whether content has changed  Two places where signatures catered for:  Sign a bundle (enveloped signature – sign what’s in the bundle)  Sign a provenance (detached signature – sign what the provenance refers to) 13 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  14. 14. Provenance 14 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  15. 15. Provenance Code Definition enterer A person entering the data into the originating system performer A person, animal, organization or device that who actually and principally carries out the activity author A party that originates the resource and therefore has responsibility for the information given in the resource and ownership of this resource verifier A person who verifies the correctness and appropriateness of activity attester A verifier who attests to the accuracy of the resource informant A person who reported information that contributed to the resource source An information source from which the portions of the resource are derived cc A party, who may or should receive or who has received a copy of the resource or subsequent or derivative information of that resource application An application with a user interface that interacts with a person daemon A background process that transfers information from one place or form to another 15 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  16. 16. Digital Signatures  There are many valid reasons for the data to change  Syntax variations & JSON vs XML  Code translations  Changing security access labels  Relocation of resources  Ongoing content editing 16 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  17. 17. Digital Signatures  Which format?  XML Digital Signature vs JSON Web Token  What canonicalization?  Sign JSON vs XML vs something else?  Current plan:  Describe canonical forms for XML and JSON  There is no syntax variation – it’s all data  Can sign with either JWT or XML DigSig  ? Support for canonicalisation of references 17 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  18. 18. Attachments  Attachments may include active content  Scripts, executable code, exploits, malicious content  Might run in a very privileged environment  Attachments may be references to external content  Allows clinical information to be tracked  Applications might leak information when accessing it 18 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  19. 19. Attachments  Maintain a whitelist of allowed content types and content servers  Scrub http headers scrupulously when accessing content (internal proxy)  http://smartplatforms.org/2014/04/security-vulnerabilities- in-ccda-display/ 19 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  20. 20. Narrative  Narrative in resources presents similar issues (HTML is very active content)  For security and clinical safety reasons, no active content is allowed  Object, embed, script tags, etc  Enforced by schema / reference implementations  But image references are still allowed – so care is still required 20 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  21. 21. Security Labels  A tag attached to the resource  Makes explicit statements about the resource content  Might be based on the resource content or not  Used by access control engine  Can convey obligations associated with the data  These are binding on any FHIR implementation 21 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  22. 22. Core Security Labels  Confidentiality Code  Celebrity / Staff  Keep information from patient  Contact/Employment Details Confidential  Diagnosis-related confidentiality  Author Consent needed  Delete After Use  Do Not Re-use  Break The Glass 22 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  23. 23. OAuth  Server must make decisions about security  Server has to identify client and give it privileges  Classically, done by a trusted connection  Server identifies client by network address, implicit trust, or client certificate  Server trusts client to identify the user  Server assigns role-based privileges to client / user 23 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  24. 24. OAuth  Static – user has no operational control  User has to trust their agent completely  User cannot choose agents  The administrator is in control  OAuth puts the user back in control  User decides how much they trust their agent  User can only grant access that they have 24 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  25. 25. OAuth  OAuth also delegates authentication of the user to the server, not the client 25 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  26. 26. Oauth - Example © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  27. 27. Oauth - Example © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  28. 28. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  29. 29. User Resources?  User Information  Email Address  Real world Identifying Information (name, etc)  Google/Facebook friend list  User specific services  Post to facebook wall  Storage (e.g. DropBox)  Health Care information © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  30. 30. OAuth Parties  User  User who wants to achieve something  Service Provider  Can authenticate the user (password etc)  Has things the user owns  Service Consumer  Needs to use User’s resources (e.g. for the user)  Trusted by the service provider and the user © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  31. 31. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  32. 32. OAuth Parties  User  User who wants to achieve something  Service Provider  Can authenticate the user (password etc)  Has things the user owns  Service Consumer  Needs to use User’s resources (e.g. for the user)  Trusted by the service provider and the user © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  33. 33. Authorization vs Authentication  Service Consumer doesn’t know who the user is  Just knows that the Service Provider authorises the consumer to do things on behalf of anonymous user  Which may include getting their identification  if service provider authenticated the user  And if the service provider as an API for that  And if the user allows it to be shared © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  34. 34. Setting OAuth Up  There must be a private agreement between the service provider and the service consumer  The service provider gives the service consumer a secret (or 2) that the user doesn’t see  The secrets are used in the exchange protocol  Service consumer might not be secure 34 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  35. 35. OAuth Flows  There are multiple “flows” – sequences of exchange. Most are variations of:  User prompts engagement  Consumer refers to User to provider (http address)  Provider authenticates user as it sees fit  Provider asks the user whether scopes are ok  Provider refers User back to consumer (http address) with a token  Consumer uses token to get access rights 35 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  36. 36. OAuth  OAuth is a framework  Like FHIR  There’s lots of ways to use it  Every implementation is different 36 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  37. 37. Using OAuth © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  38. 38. Using OAuth 38  Consumer (client) delegates Authorization to Provider (server)  Server can delegate Authentication to another party (Double Layer OAuth)  Demonstration  http://www.healthintersections.com.au/?p=2108 (includes Josh Mandel’s excellent video) © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  39. 39. Scopes  Service Consumer requests a set of permissions – “scopes”  Service Provider checks these with the user  Service Provider tells Service Consumer what permissions the user granted  All 3 parties have to agree on scopes 39 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  40. 40. Possible Scopes  Access identifying information  Access to a particular patient compartment  Read access to all resources  Write access to a resource type  Create operation on Observation Resource  Read/write all medication resources  Mental Health related history 40 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  41. 41. OAuth Pro’s & Cons  Dynamic Permission Assignment  Delegate User Authentication  Relatively Simple API  Can Compose amazing services  Framework not solution  Documentation confusing and byzantine  Errors obtuse and misleading  Not a full solution yet © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  42. 42. Conclusion  This remains an ongoing area that will drive more new versions of the specification  We currently plan to migrate the SMART-On- FHIR security parts to FHIR once they are stable 42 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  • nininnt

    May. 8, 2017
  • KuladeepSurisetti

    Mar. 2, 2017
  • ThorSchliemann

    Sep. 27, 2016
  • AndreKrueger2

    Nov. 30, 2015
  • mruau

    Aug. 4, 2015
  • omarps80

    Jun. 5, 2015

Security in FHIR with OAuth by Grahame Grieve

Vistos

Vistos totais

3.169

No Slideshare

0

De incorporações

0

Número de incorporações

368

Ações

Baixados

212

Compartilhados

0

Comentários

0

Curtir

6

×