The document outlines the architecture and issues related to identity, authentication, and authorization within IoT systems, focusing on communication strategies and usability challenges. It highlights problems with existing models, such as multiple identity providers and the necessity for effective identity relationship management. A proposed solution involves leveraging control systems as identity providers and improving synchronization methods between cloud and local identities.

1. IoT Mobile App/Device/Field
Gateway and Cloud Identity &
Security architecture
Prepared By Vinod Wilson
Architect, Crestron Electronics

2. Agenda
• Communication Strategy
• Current Architecture
• Problems in current architecture
• Multiple IDPs
• Usability
• Synchronization
• Identity / Authentication / Authorization ( IAM & IRM )
• Cloud Capabilities
• Proposed Solution

3. Communication Strategy
• Cloud First
• Mobile First
• Offline First
• Offline First
• Mobile First
• Cloud First

4. Problems in Security architecture
• Strategy changed from Offline-First to Cloud First
• User Experience
• User has to wait for 10 minutes to really connect to any device
• Multiple IDPs
• Identity
• Identity and Access Management (IAM)
• Roles & Group policy
• Roles & Group policy per device
• Identity Relationship Management (IRM)

5. Identity
• Identity = set of attributes related to an entity [iso 29115]
Entity Identity
6’ 5” Tall
Grey Hair Man
Work
Husband
Father
Women
Mother
Daughter
Wife
Girl FriendFriend
Boss
Collegue
Identity is Context Driven
For each context, the attribute differs
Identity1
Identity2
Identity3

6. Evolution of Identity
Employees
Consumers
Employees &
Partners
Things
Perimeter
Perimeter
Federation
Perimeter-less
Federation
Cloud / SaaS
Perimeter-less
Federation
Cloud
SaaS
Mobility
Attributes
Context
Stateless
Relationships

7. What Identity Layer provides
• Is the user that got authenticatedWho
• Was he authenticatedWhere
• Was he authenticatedWhen
• Was he authenticatedHow
• Attributes he can give youWhat
• He is providing themWhy

8. Authentication
• The best usability for authentication is never asking you to authenticate, just
knowing who you are.
• Authentication involves Trade-offs
Usability

9. Authentication
• Traditional NTLM / Kerberos authentication
• Claims based Authentication
• Protocols
• OpenID Connect
• Attribute & Cryptography
• Authorization
• OAUTH 2.0

10. Claims based Authentication

11. How OAuth Was Born?
My Brand
New Ferrari
Let me
Park it
sir!Parking
Key
Allow the owner to provide limited authorization to valet
attendants
OAuth was created to solve the same core issue online

12. Claims based Authentication

13. OAUTH

14. OAuth2 Client Profiles
• Web Application
• User Agent
• Native

15. OAuth2 Client Profiles
Web Application User Agent Native

16. OAUTH Authorization Grant

17. Mechanics of Token Validation
• Verify that it is well-formed
• Token must be digitally signed
• Verify that it is coming from the intended authority
• Signature verification
• Issuer value
• Verify that it is meant for the current application

18. Access control & Policy Management
• Access Control Models
• Mandatory Access Control (MAC)
• Discretionary Access Control (DAC)
• Role-based access control (RBAC)
• Do not take into account additional parameters such as
• Resource information,
• Relationship between the user (the requesting entity) and the resource, and
• Dynamic information e.g. time of the day or user IP, geolocation coordinates
• Attribute-based access control (ABAC)
• XACML (eXtensible Access Control Markup Language)
• UMA(User Managed Access) Profiles for OAUTH 2.0
• In other words selective sharing
User-Centric

19. Web Application Access Control
if (User.IsInRole("Role01") || User.IsInRole("Role02") || User.IsInRole("Role03"))
{
return RedirectToAction("Secure", "Home");
}
else
{
return RedirectToAction("Index", "Home");
}
1. Roles & Group policy per device
2. Change the user role Dynamically
1. Change the role in the token or get a new token from AS with a changed role
2. Manually apply the logic of role change

20. Identity Problems in IoT
Unreasonably large number of relationships among an unreasonably large
numbers of people and things

21. Identity Relationship Management ( IRM )
• Person-to-Person
• Thing-to-Thing
• Person-to-Thing

22. Identity Relationship Management ( IRM )
•Relationships must be scalable
•Actors, Attributes, Relationships, AdministrationScalable
•In a traditional IAM scenario, we pass actionable information to the
back-end for a classic request-response authorization modelActionable
•PYNG-HUB was made by CrestronImmutable
•Temporary
•PermanentTransferable
•Single-party Asserted, Multi-party AssertedProvable
•Must all parties in a relationship acknowledge they are in a
relationship?Acknowledgeable
•Can either party revoke a relationship?
•Does this imply the idea of cascading deletes?Revocable

23. Identity Relationship Management (IRM)
• In an IRM (and IoT) world
• There is little to no connectivity to a backend authority
• That a back-end authority simply does not exist
• Does a protocol exist today?
• NO
• But anything is happening to address this issue?
• YES

24. So Far - Recap
• Identity
• Authentication
• Access & Policy Management
• Identity relationship management ( IRM)

25. Multiple IDPs and Synchronization Problem
Azure AD
Cloud Service
Cloud App Service

26. Authentication
• Traditional NTLM / Kerberos authentication
• Claims based Authentication
• Protocols
• OpenID Connect
• Attribute & Cryptography
• Authorization
• OAUTH 2.0

27. Synchronization – Microsoft Sync Framework

28. Synchronization
• History
• Microsoft Sync Framework
• 1.0 Published on 2006
• 1.0 SP1 Published on 4/12/2010
• 2.1 Published on 8/18/2010
• Sync Framework 4.0 October 2010 CTP
• STOPPED
• Azure AD Hybrid problem
• Azure AD Connect Preview
• 24 Mar 2015

29. What others have to say on Identity/Authentication/Authorization?

30. Security Challenges within IoT Systems
• Designed to operate autonomously in the field with no backup connectivity
if primary connection is lost
• The IoT entities will generally not be a single-use, single-ownership solution
• central security management user interface
• To enable the homeowner to manage who has the capability to access their home
• Can be used to control other IOT devices that have API’s
• If every IOT device in your home has its own security management web interface, it
won’t scale
• Using a central policy decision point (UMA Profile for OAUTH 2.0), people can
manage in one place which policies apply to what, without having to go to the web
admin page of every device

31. CISCO IOT Security
• The IoT/M2M endpoints must be
fingerprinted by means that do
not require human interaction.
Such identifiers include
• RFID
• Shared Secret
• X.509 Certificates
• MAC Address of the endpoint
• Some type of immutable hardware
based root of trust

32. Third-Party System comparison
• Philips Hue Lighting System
• Offline-First
• Away from Home authentication
• Single IDP
• SmartThings Hub
• Cloud-First
• Away from Home authentication
• Single IDP

33. Philips Hue Lighting System
• The bridge communicates directly with the LED bulbs using
theZigBee protocol, which is built upon the IEEE 802.15.4 standard

34. Bride registering with the cloud service
• id (a unique id is assigned to
every physical bridge
manufactured),
• internal IP address, and
• MAC address (identical to the id)

35. Controlling Lights via the Website Interface
This website is served from internet

36. Is button Pressed?
GET /en-US/user/isbuttonpressed HTTP/1.1
Host: www.meethue.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.28.10
(KHTML, like Gecko) Version/6.0.3 Safari/536.28.10
Accept: */*
DNT: 1
X-Requested-With: XMLHttpRequest
Referer: https://www.meethue.com/en-US/user/linkbridge
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie:[DELETED]
Connection: keep-alive
Proxy-Connection: keep-alive
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: PLAY_FLASH=;Path=/;Expires=Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: PLAY_ERRORS=;Path=/;Expires=Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: [DELETED]
Vary: Accept-Encoding
Date: Mon, 29 Apr 2013 23:30:06 GMT
Server: Google Frontend
Content-Length: 4
true
Request Response

37. Complete setup
GET /en-US/user/setupcomplete HTTP/1.1
Host: www.meethue.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3)
AppleWebKit/536.28.10
(KHTML, like Gecko) Version/6.0.3 Safari/536.28.10
Accept: text/html,application/xhtml+xml,application/xml;
DNT: 1
Referer: https://www.meethue.com/en-US/user/linkbridge
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: [DELETED]
Connection: keep-alive
Proxy-Connection: keep-alive
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8; charset=utf-8
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: PLAY_FLASH=;Path=/;Expires=Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: PLAY_ERRORS=;Path=/;Expires=Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: PLAY_SESSION="[DELETED]-%00ip_address%3A[DELETED]__[DELETED]
;Path=/
Vary: Accept-Encoding
Date: Mon, 29 Apr 2013 23:30:08 GMT
Server: Google Frontend
Content-Length: 47369
[DELETED]
app.data.bridge = {"clientMessageState":[DELETED],"config":{"lights":{"15":
{"name":"Bathroom 2","state":{"bri":254,"effect":"none","sat":144,"reachabl
e":true,"alert":"none","hue":14922,"colormode":"ct","on":false,"ct":369,"xy
":[0.4595,0.4105]},"modelid":"LCT001","swversion":"65003148"
Request Response

38. Bridge Now available

39. Sending commands to the bridge
• The token obtained from the previous step is being sent to the bridge
directly along with the commands.
• In Local network
• Commands are directly sent to the bridge
• When Away from Home
• Commands are sent via the cloud

40. Controlling Lights Using the iOS App
GET /api/[username MD5 Hash of MacID] HTTP/1.1
Host: 10.0.1.2
Proxy-Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-us
Connection: keep-alive
Pragma: no-cache
User-Agent: hue/1.1.1 CFNetwork/609.1.4 Darwin/13.0.0
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-
check=0, pre-check=0
Pragma: no-cache
Expires: Mon, 1 Aug 2011 09:00:00 GMT
Connection: close
Access-Control-Max-Age: 0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT,
DELETE
Access-Control-Allow-Headers: Content-Type
Content-type: application/json
[{"error":{"type":1,"address":"/","description":"unauthorized
user"}}]
Request Response

41. Identity / Authentication
POST /api HTTP/1.1
Host: 10.0.1.2
Proxy-Connection: keep-alive
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-
form-urlencoded
Accept-Language: en-us
Accept: */*
Pragma: no-cache
Connection: keep-alive
User-Agent: hue/1.1.1
CFNetwork/609.1.4 Darwin/13.0.0
Content-Length: 71
{"username":"[username
DELETED]","devicetype":"iPhone
5"}
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache,
must-revalidate, post-check=0, pre-
check=0
Pragma: no-cache
Expires: Mon, 1 Aug 2011 09:00:00
GMT
Connection: close
Access-Control-Max-Age: 0
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST,
GET, OPTIONS, PUT, DELETE
Access-Control-Allow-Headers:
Content-Type
Content-type: application/json
[{"success":{"username":"[username
DELETED]"}}]
Request Response

42. Away From Home setup

43. Away from home setup complete
GET /en-US/api/getaccesstokenpost HTTP/1.1
Host: www.meethue.com
Referer: https://www.meethue.com/en-US/api/getaccesstokengivepermission
Proxy-Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Cookie: [DELETED]
Accept-Language: en-us
Connection: keep-alive
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_4 like Mac OS X)
AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B350
Safari/8536.25
Request

44. SmartThings
The SmartThings Hub uses the ZigBee protocol to communicate
with the nearby devices

45. SmartThings Statement
• We made the decision at SmartThings to support a “Cloud First” approach for our platform. This
means that in our initial release, there is a dependency on the Cloud. SmartApps run in the
SmartThings Cloud, so for everything to work, your hub does need to be online and connected to
our cloud. This will generally be the case, even when we implement hub-local capabilities as
described below.
• We believe in a “connected” service where local capabilities in the hub are meant to improve
performance and insulate the customer from intermittent internet outages. We do not plan to
support a perpetually disconnected mode.
• We made the decision to limit SmartApps to the Cloud in our first release because it allowed us to
focus on the experience of writing the applications and less on the mechanics of deploying that
logic locally to the hub.
• That said, we are actively considering implementation scenarios whereby we can distribute
SmartApps to—and execute SmartApps locally on—the SmartThings Hub.
• In all cases, we recognize the critical scenarios where a loss of communications with the
SmartThings Cloud could have a degrading impact on critical, local use cases, and are being
deeply thoughtful on how we minimize the risk of disruption.

46. Proposed Solution
• If in case the control system also acts as a Identity Provider, other
than the central cloud Identity Provider, then for offline-first scenario
it is better to cache the credentials in the control system
• Currently there is no standard way to synchronize the cloud IDP and
Control System IDP, hence synchronization of identity information
between the control system and the cloud should be done using
versioning
• UMA profiles should be considered for issues related to IRM