Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

UMA as Authorization mechanism for IoT: a healthcare scenario

3,682 views

Published on

Presentation at Kantara Initiative workshop at Utrecht, 4-5th September 2014. UMA as Authorization mechanism for IoT: a healthcare scenario.

Published in: Software
  • Be the first to comment

UMA as Authorization mechanism for IoT: a healthcare scenario

  1. 1. UMA as Authorization mechanism for IoT A healthcare use case Domenico Catalano, Oracle Italy Maciej Machulak, Cloud Identity Limited ! Kantara Initiative Workshop 4-5th Sept. 2014 - Utretch 1
  2. 2. Agenda Problem Statements Scenario and Requirements UMA Concepts Architecture Q&A 2
  3. 3. Authorization Definition A process for granting approval to a system entity to access a system resource. 3 System Resource System Entity Internet Security Glossary, Version 2 (RFC 4949) Access
  4. 4. Nature and Complexity of an IoT Environment 4 Identity & Ownership Objects with limited capability Distributed Objects Hierarchy & Delegation External Applicatio n Proprietary Protocols
  5. 5. Authentication and Authorization in Constrained Environment (ACE) Actors in the ACE Architecture http://tools.ietf.org/pdf/draft-gerdes-ace-actors-01.pdf 5
  6. 6. User-Managed Access (UMA) Architecture and Terminology manage control Protect with PAT 6 Resource Server Resources Resource Owner Authorization Server Authorization API UMA Client Protection API PAT Access RPT AAT with RPT Client redirects the Requesting Party to AS on behalf of Requesting Party PAT: Permission Access Token AAT: Authorization Access Token RPT: Requesting Party Token
  7. 7. UMA as Authorization mechanism for IoT Day Hospital scenario • Alice is admitted to Hospital, for a checkup, where she is assigned a bed with a Monitoring device system (Smart Device). • The doctor (Bob) checks Alice with his Electronic Stethoscope, which is able to record and store patient’s heartbeats. • Patient’s heartbeats must be shared with EHR system and with an external provider for analysis. 7
  8. 8. 8
  9. 9. Day Hospital Use Case Actors and Resources Patient’s Security Domain Access Access 9 Resource Owner Resource Client Owner Resource Owner Requesting Party Resource Client Doctor’s Security Domain Hospital’s Security Domain
  10. 10. Day Hospital Use Case Actors and Resources Patient’s Security Domain Access Access 10 Resource Owner Stethoscope Client Owner Resource Owner Requesting Party Resource EHR System Doctor’s Security Domain Hospital’s Security Domain Smart Device Object Interface Network Interface Patient Data
  11. 11. Assumptions • Electronic Stethoscope is a device with limited capabilities (records, stores and signs heartbeats data). • The Patient’s bed embeds a smart device (Patient monitoring,) which is able to connect with external devices and provides an IP connectivity. • The healthcare’s Smart Devices are registered with NHS, which acts as trusted party. 11
  12. 12. Day Hospital Use Case Internet of Things High Level Architecture 12 B A Resource Owner Hospital UMA Authorization System Cloud Provider EHR data data data Trusted Network of Objects data Smart Device Resource Personal Owner UMA Authorization System Doctor Patient Resource Resource
  13. 13. Goals • G1. Doctor must able to register his own resource (stethoscope) to the Authorization System. • G2. Patient must be able to register the monitoring device system as protected resource • G3. Doctor must be able to authorize and delegate a client to access to his resource. • G4. Patient must be able to express consent for sharing his own data (heartbeats) with other parties. 13
  14. 14. Requirements • Resource Registration, Discovery Services • Actions Delegation • Patient Consent • Access Control for sharing data 14
  15. 15. Resources Registration Dynamic Registration 15 Resource Owner Personal UMA Authorization System Patient B A Hospital Objects Day Hospital Request Operator Assign Resource National Healthcare System sw_stmt Secret Object Enrollment AuthN 1 2 3 OAuth 2.0 Dynamic Client Registration Protocol
  16. 16. UMA Authorization Flow Client Resource Resource Owner 1. The Smart Device reveals a electronic stethoscope. 2. The Smart Device (Client) attempts to access to the heartbeats data (Resource). 3. The Smart Device (Client) is re-direct to the Doctor’s Authorization Server for the authorization process. 16
  17. 17. Patient’s Monitoring System Smart Device Electronic Stethoscope Authorization Process Redirect to UMA AS… 17
  18. 18. Patient’s Monitoring System Smart Device National Healthcare System Authentication Service Fingerprint 18
  19. 19. Patient’s Monitoring System Smart Device UMA Authorization Server Access Request Allow Cancel 19
  20. 20. Patient’s Monitoring System Smart Device Electronic Stethoscope data uploading… Patient’s data association 20
  21. 21. A new Protected Resource is added to Personal UMA AS 21 Resource Owner Personal UMA Authorization System Patient B New Protected Resource Get Access Hospital Objects Notification Smart 2 1 Device 3
  22. 22. Patient Notification Personal UMA AS Heartbeat data added as protected resource View Close 22 Alice
  23. 23. Actions Delegation • The doctor needs share patient’s heartbeats data with EHR system and an external party. • The sharing policy should be inherited by the mediator client (smart device) which will act as resource server for the EHR system and external Requester. 23
  24. 24. Delegation Process www.uma4IoT.com/am/ObjectDelegation Share with EHR System Share with Healthcare Provider 24 Hospital UMA Authorization System Objects Request Delegation App Actions Data Protection Anonymous data Patient consent Period: from __/__/____ to __/__/____ Welcome Bob
  25. 25. Inherited Data Sharing Policy 25 Alice Resources Heatbeats Description Data Sharing Policy Data Protection Share with EHR System Share with Healthcare Provider
  26. 26. Client Access and Patient Consent UMA Flow Protect with PAT 26 Heartbeats data PAT: Permission Access Token AAT: Authorization Access Token RPT: Requesting Party Token Patient Resource Owner Authorization Server Authorization API EHR System UMA Client Protection API manage Consent PAT Access RPT AAT with RPT Client redirects the Requesting Party to AS Patient Device Monitoring Requesting Party IdP/Claim Provider Claim Client Authenticate Request UserInfo
  27. 27. UMA Trust Model Trust Chain Client Resource 27 Identity Assurance Resource Owner Authorize Trust Framework ISO 29115 Trustworthiness Delegation Server Trusted Claims Registration Authorization Server Protect (on behalf of Requesting Party) Access Accreditation System
  28. 28. Advantages of UMA Approach • Designed for centralising the authorization process for distributed resources. •Works with constrained resources, requires web stack. • Applicable to different nature of objects, data and owners. • Developed to meet the Privacy By Design principles. 28
  29. 29. Acknowledgements • Eve Maler - Chair UMA WG • UMA Work Group • User-Managed Access (UMA) Core Protocol • OAuth 2.0 Dynamic Client Registration Protocol • Securing Internet of Things • Actors in the ACE Architecture 29 References
  30. 30. Questions? Thank you @UMAWG tinyurl.com/umawg |tinyurl.com/umafaq 30

×