Embed Size (px)
DESCRIPTION
Talk delivered by Eve Maler (@xmlgrrl), ForgeRock VP of Innovation and Emerging Technology, at the IOTA Conference on 20 October 2014: 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.
Citation preview
Consumerizing Industrial IoT Access Control
Using UMA to Add Privacy and Usability to Strong Security
FORGEROCK.COM
Eve Maler VP Innovation & Emerging Technology [email protected] @xmlgrrl
October 2014
2
Agenda
■ Who am I? ■ Authorization challenges ■ Testing out web authorization solutions
■ Introducing User-Managed Access (UMA) ■ Conclusions and future work
Constrained environments present major authorization
challenges
h/t @gffletch, @domcat
4
We need it for Internet-connected dishwashers…
flickr.com | n1ct4yl0r | CC BY-NC-ND 2.0 | link
5
…smart medical thingies…
6
…and Solar Freakin’ Roadways
7
What are the requirements?
Scale Discovery
8
What are the requirements?
Privacy Flexibility
flickr.com | ahilliker | CC BY-NC-ND 2.0 | link
9
What are the requirements?
Partitioning
How far do existing web authorization and consent
technologies take us?
flickr.com | smemon | CC BY 2.0 | link
11
Extensible Access Control Markup Language (XACML)
Scale Discovery Privacy
Flexibility Partitioning
X ?
X
X ?
12
OAuth 2.0 Authorization Framework
Scale Discovery Privacy
Flexibility Partitioning
?
?
? ?
13
How do we share data informally on the web? It’s not good…
flickr.com | thomashawk | CC BY-NC 2.0 | link
Introducing User-Managed Access (UMA)
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
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
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
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
UMA-enabled systems can respect policies such as…
Only let my tax preparer with email [email protected] 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
The user experience can simulate OAuth or proprietary sharing paradigms, or even be invisible (“better than OAuth”)
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
UM
A-enabled
client
RPT
requesting party token
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 A
PI P
rote
ctio
n cl
ient
PAT
protection API token
• Resource registration endpoint • Permission registration endpoint • Token introspection endpoint
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
Authorization client
AAT authorization API token
• Authorization request endpoint
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
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
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
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)
Conclusion and next steps
29
UMA use-case scenario domains Health
Financial
Education
Personal
Citizen
Media
Behavioral
Web
Mobile
API
IoT
30
UMA wrt the the “ACE actors”
Partitioning
31
How does User-Managed Access do?
Scale Discovery Privacy
Flexibility Partitioning
?
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
