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

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 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

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

Thank you!

FORGEROCK.COM

Eve Maler VP Innovation & Emerging Technology eve.maler@forgerock.com @xmlgrrl