The document discusses the challenges of authorization for constrained environments like IoT devices and proposes a solution called User-Managed Access (UMA). UMA is a draft standard that uses OAuth to enable selective sharing of resources through centralized authorization servers. This allows resource owners like users to control access through policies while respecting privacy. The approach was tested for applications like fitness devices and addresses challenges like scale, discovery, flexibility and partitioning of authorization for complex modern systems. Future work is needed to refine UMA for disconnected IoT environments.

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
Agenda
■ Who am I?
■ Authorization challenges
■ Testing out web authorization solutions
■ Introducing User-Managed Access (UMA)
■ Conclusions and future work

3. Constrained environments
present major authorization
challenges
h/t @gffletch, @domcat

4. 4
We need it for Internet-connected
dishwashers…
flickr.com | n1ct4yl0r | CC BY-NC-ND 2.0 | link

5. 5
…smart medical thingies…

6. 6
…and Solar Freakin’ Roadways

7. 7
What are the requirements?
Scale Discovery

8. 8
What are the requirements?
Privacy Flexibility
flickr.com | ahilliker | CC BY-NC-ND 2.0 | link

9. 9
What are the requirements?
Partitioning

10. How far do existing web
authorization and consent
technologies take us?
flickr.com | smemon | CC BY 2.0 | link

11. 11
Extensible Access Control
Markup Language (XACML)
Scale
Discovery
Privacy
Flexibility
Partitioning
X
X
?
X
?

12. 12
OAuth 2.0 Authorization
Framework
Scale
Discovery
Privacy
Flexibility
Partitioning
?
?
?
?

13. 13
How do we share data informally
on the web? It’s not good…

14. flickr.com | thomashawk | CC BY-NC 2.0 | link
Introducing User-Managed
Access (UMA)

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
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
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
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
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
The user
experience
can simulate
OAuth or
proprietary
sharing
paradigms, or
even be invisible
(“better than
OAuth”)

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
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
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
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
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
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
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. Conclusion and next steps

29. 29
UMA use-case scenario domains
Health
Financial
Education
Personal
Citizen
Media
Behavioral
Web
Mobile
API
IoT

30. 30
UMA wrt the the “ACE actors”
Partitioning

31. 31
How does User-Managed
Access do?
Scale
Discovery
Privacy
Flexibility
Partitioning
?

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. Thank you!
FORGEROCK.COM
Eve Maler
VP Innovation & Emerging Technology
eve.maler@forgerock.com
@xmlgrrl