CIS 2015 Identity Relationship Management in the Internet of Things
12
IDENTITY RELATIONSHIP MANAGEMENT IN THE INTERNET OF THINGS TRIANGULATING PEOPLE, DEVICES, AND SERVICES Eve Maler | @xmlgrrl | [email protected] 10 June 2015
-
Upload
cloudidsummit -
Category
Technology
-
view
82 -
download
4
Transcript of CIS 2015 Identity Relationship Management in the Internet of Things
IDENTITY RELATIONSHIP MANAGEMENT IN THE INTERNET OF THINGS
TRIANGULATING PEOPLE, DEVICES, AND SERVICES
Eve Maler | @xmlgrrl | [email protected] 10 June 2015
From the web to the IoT,
the “fear/greed” tension around data sharing is
growing
If privacy isn’t secrecy, what does IRM need to make selective data sharing viable?
Context The right moment to make the decision to share
Control The ability to share just the right amount
Choice The true ability to say no and to change one’s mind
Respect Regard for one’s wishes and preferences
Existing consent tools, are good, but… OAuth: standard and scoped…but opt-in, point-to-point, and single-party
“Share”: proactive and party-to-party…but proprietary, point-to-point, and often insecure
The new Venn of access
control and consent
Organizations need UMA to deliver selective sharing in IoT environments
The mechanism:
federated authorization
on top of OAuth
Loosely coupled to enable centralized authorization-as-a-service for any number of an individual’s resource servers
A new concept, to enable party-to-party sharing driven by policy (or access approval) rather than requiring the individual to be present at access time
Authorization data is added to this token if trust in the requesting party is successfully elevated, typically through authentication and/or claims-gathering
Let’s see it in action with a connected-car scenario
What just happened?
Resource owner
Resource server
Authoriza0on server
Client
Authoriza0on API
UI
UI
UI
Reques,ng party
Protec0on API
Authoriza*on client
Protec*on client
RS-‐specific API
RS-‐specific client
2
1
5 RPT
6
7
8
3
4
PAT
11
AAT
PAT
PAT
RPT
chooses resources to protect – out of band
sets policies – out of band
AAT
9
10
PAT
RS needs OAuth client creden,als at AS to get PAT C needs OAuth client creden,als at AS to get AAT All protec,on API calls must carry PAT All authoriza,on API calls must carry AAT 1. RS registers resource sets and scopes (ongoing
– CRUD API calls) 2. C requests resource (provisioned out of band;
must be unique to RO) 3. RS registers permission (resource set and
scope) for aQempted access 4. AS returns permission 0cket 5. RS returns error 403 with as_uri and
permission 0cket 6. C requests authz data, providing permission
0cket 7. (AVer claims-‐gathering flows not shown) AS
gives RPT and authz data 8. C requests resource with RPT 9. RS introspects RPT at AS (default profile) 10. AS returns token status 11. RS returns 20x
UProtect
DriveSafe, then
AllForYourCar
DriveSafe
Hans
Alice
Taking this “webby” approach to IoT sharing relationships requires careful attention
A deeper “systems design” view of vulnerabilities is required – e.g….
Authentication and linkages have new constraints – but also new options
logical physical
Access control must fail closed
Life and limb is at risk if access control fails
closed
Usually the “constrained entity” (if there is one); often a device paired to a service
and gateway
Is a connection available at access attempt time? What
to do if not?
THANKS!
Eve Maler (@xmlgrrl)
