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.

Consumerizing Industrial IoT Access Control: Using UMA to Add Privacy and Usability to Strong Security

1,861 views

Published on

On 20 October 2014, I spoke at #IOTAconf at Moscone Center in SF (with awesome display help from Param Singh!) on "Consumerizing Industrial IoT Access Control : Using UMA to Add Privacy and Usability to Strong Security".

Abstract: "The first couple of chapters of authorization and access control are still being written even when it comes to old-fashioned web services and newfangled APIs, never mind the Internet of Things. IoT security has needs that go way beyond the current scope of cloud and mobile challenges: super-loosely coupled, super-strong, and more. Everyone can imagine security-gone-wrong scenarios that have disastrous consequences for industrial IoT use cases. For consumer-facing IoT in healthcare, household appliances, and more, the consequences are different but no less severe, and it adds a killer requirement: privacy. How can we solve the problems of access control and privacy in a unified way, without compromise? And how can we solve the problem NOW? The OAuth-based User-Managed Access (UMA) protocol provides answers."

Published in: Technology
  • Be the first to comment

Consumerizing Industrial IoT Access Control: Using UMA to Add Privacy and Usability to Strong Security

  1. 1. Consumerizing Industrial IoT Access Control Using UMA to Add Privacy and Usability to Strong Security FORGEROCK.COM Eve Maler VP Innovation & Emerging Technology eve.maler@forgerock.com @xmlgrrl October 2014
  2. 2. 2 Agenda ■ Who am I? ■ Authorization challenges ■ Testing out web authorization solutions ■ Introducing User-Managed Access (UMA) ■ Conclusions and future work
  3. 3. Constrained environments present major authorization challenges h/t @gffletch, @domcat
  4. 4. 4 We need it for Internet-connected dishwashers… flickr.com | n1ct4yl0r | CC BY-NC-ND 2.0 | link
  5. 5. 5 …smart medical thingies…
  6. 6. 6 …and Solar Freakin’ Roadways
  7. 7. 7 What are the requirements? Scale Discovery
  8. 8. 8 What are the requirements? Privacy Flexibility flickr.com | ahilliker | CC BY-NC-ND 2.0 | link
  9. 9. 9 What are the requirements? Partitioning
  10. 10. How far do existing web authorization and consent technologies take us? flickr.com | smemon | CC BY 2.0 | link
  11. 11. 11 Extensible Access Control Markup Language (XACML) Scale Discovery Privacy Flexibility Partitioning X X ? X ?
  12. 12. 12 OAuth 2.0 Authorization Framework Scale Discovery Privacy Flexibility Partitioning ? ? ? ?
  13. 13. 13 How do we share data informally on the web? It’s not good…
  14. 14. flickr.com | thomashawk | CC BY-NC 2.0 | link Introducing User-Managed Access (UMA)
  15. 15. 15 UMA in a nutshell ■ Draft standard for “authorization V.next” ■ Profile and application of OAuth V2.0 ■ Set of authorization, privacy, and consent APIs ■ Work Group of the Kantara Initiative ■ Founder, chair, and “chief UMAnitarian”: ■ Heading to V1.0 in Q1 2015 ■ In interop testing now
  16. 16. 16 The UMA protocol enables key new selective sharing options I want to share this stuff selectively • Among my own apps • With family and friends • With organizations I want to protect this stuff from being seen by everyone in the world I want to control access proactively, not just feel forced to consent over and over
  17. 17. 17 Under the hood, it’s “OAuth++” Loosely coupled to enable an AS to onboard multiple RS’s, residing in any security domains This concept is new, to enable person-to-person sharing driven by RO policy vs. run-time consent
  18. 18. 18 UMA is about interoperable, RESTful authorization-as-a-service Has standardized APIs for privacy and “selective sharing” Outsources protection to a centralizable authorization server “authz provider” (AzP) “authz relying party” (AzRP) identity provider (IdP) SSO relying party (RP)
  19. 19. 19 UMA-enabled systems can respect policies such as… Only let my tax preparer with email TP1234@gmail.com and using client app TaxThis access my bank account data if they have authenticated strongly, and not after tax season is over. Let my health aggregation app, my doctor’s office client app, and the client for my husband’s employer’s insurance plan (which covers me) get access to my wifi-enabled scale API and my fitness wearable API to read the results they generate. When a person driving a vehicle with an unknown ID comes into contact with my Solar Freakin’ Driveway, alert me and require my access approval.
  20. 20. 20 The user experience can simulate OAuth or proprietary sharing paradigms, or even be invisible (“better than OAuth”)
  21. 21. 21 The RS exposes whatever value-add API it wants, protected by an AS The RPT is the main “access token” and (by default – it’s profilable) is associated with time-limited, scoped permissions App-specific API UMA-enabled client RPT requesting party token
  22. 22. 22 The AS exposes an UMA-standardized protection API to the RS The PAT protects the API and binds the RO, RS, and AS Protection API Protection client PAT protection API token • Resource registration endpoint • Permission registration endpoint • Token introspection endpoint
  23. 23. 23 The AS exposes an UMA-standardized authorization API to the client The AAT protects the API and binds the RqP, client, and AS The client may be told: “need_claims” Authorization API AAT Authorization client authorization API token • Authorization request endpoint
  24. 24. 24 The AS can collect requesting party “claims” to assess policy A “claims-aware” client can proactively push an OpenID Connect ID token, a SAML assertion, a SCIM record, or other available user data to the AS per the access federation’s trust framework A “claims-unaware” client can, at minimum, redirect the requesting party to the AS to log in, press an “I Agree” button, fill in a form, follow a NASCAR for federated login, etc.
  25. 25. 25 Applying the UMA paradigm to a fitness wearable use case ■ The device user is the resource owner, with discretionary resource access control rights – Access control confers proactive privacy capabilities through policy ■ The device+service combination is likely to use an (out-of-band wrt UMA) constrained-device IoT protocol
  26. 26. 26 Benefits of the approach ■ Flexibility in binding an individual to a device and to a corresponding service account – Enables persistent or temporary device controllers ■ Flexibility and centralization in letting an individual choose sharing settings – Accommodating OAuth-style sharing with apps that the device user himself uses and also third parties ■ Comprehensive yet simple platform approach to device service protection and access control – Enabling third-party services and devices to join an ecosystem ■ Future-proofing if the platform operator needs to outsource protection to regulation-driven, consumer-driven, or healthcare-ecosystem-driven authorization services
  27. 27. 27 Concept mappings ■ Device user ■ Device + service ■ Device certificate ■ Service APIs exposing PII ■ IoT identity/authorization platform ■ PII-accessing web/native app ■ PII-accessing app credentials ■ User of PII-accessing app ■ Onboarding device + user ■ Onboarding app + user ■ Device user sharing policy ■ Dynamic entitlement management ■ UMA resource owner (RO) ■ UMA resource server (RS) ■ UMA RS OAuth client credentials ■ UMA protected resources ■ UMA authz server (AS) ■ UMA client ■ UMA client OAuth client credentials ■ UMA requesting party (RqP) ■ Protection API token (PAT) ■ Authz API token (AAT) ■ RqP claims-gathering ■ UMA requesting party token (RPT)
  28. 28. Conclusion and next steps
  29. 29. 29 UMA use-case scenario domains Health Financial Education Personal Citizen Media Behavioral Web Mobile API IoT
  30. 30. 30 UMA wrt the the “ACE actors” Partitioning
  31. 31. 31 How does User-Managed Access do? Scale Discovery Privacy Flexibility Partitioning ?
  32. 32. 32 Next steps and future work ■ A variety of IoT, web, and API case studies have been contributed ■ Enterprise API use cases have been deployed in production ■ Open source is available and more is expected ■ Intel has done an experimental industrial IoT implementation in node.js ■ V1.0 of the protocol is slated to be completed in Q1 2015 ■ Further IoT investigation on disconnected operation modes, proof-of-possession tokens, etc. is warranted
  33. 33. Thank you! FORGEROCK.COM Eve Maler VP Innovation & Emerging Technology eve.maler@forgerock.com @xmlgrrl

×