authorization aspects of the distributed dataflow-oriented iot framework calvin

Introduction to CalvinAuthorization Considerations

Authorization in CalvinDemo

Authorization Aspects of the DistributedDataflow-oriented IoT Framework Calvin

Master’s Thesis

Tomas Nilsson

June 8, 2016

Tomas Nilsson Authorization Aspects of the IoT Framework Calvin 1 / 20



Presentation Outline

I Introduction to CalvinI Authorization Considerations

I Aims and challenges for this master’s thesis work

I Authorization in CalvinI What have I implemented?

I Demo




Distributed Cloud for IoTApplications and ActorsMigration, Capabilities, and Requirements

Calvin – Distributed Cloud for IoT

I Open-source framework developed by Ericsson Research

I Simplify development of distributed applications combiningIoT and cloud computing

I Execute different parts of the application on different devices

I Migrate to other devices without interrupting execution

I Calvin runtime handles data transport, message parsing,scheduling, etc.





Calvin – Applications and Actors

I Dataflow programming methodologyI Actors perform certain tasksI Application defines how data flows between actors

State Requirements

Action outin

Actor





Calvin – Applications and Actors

I Dataflow programming methodologyI Actors perform certain tasksI Application defines how data flows between actors

I Application example:

button

io.GPIOReader

state

camera

media.Camera

trigger image

screen

media.ImageRenderer

image





Calvin – Migration, Capabilities, and Requirements

Before migration

A

B

Runtime 1

B

C

Runtime 2

B

CActor 1

CActor 3

AActor 2

Requirements

Capabilities &Attributes





Calvin – Migration, Capabilities, and Requirements

After migration

A

B

Runtime 1

B

C

Runtime 2

AActor 2

B

CActor 1

CActor 3




Aims and ChallengesAttribute-Based Access ControlAdaptable to Constrained Devices

Aims and Challenges for this thesis work

Implement authorization of applications/actors in Calvin

Desired Functionality:

3 Fine-grained authorization decisions on access to resources offeredby a runtime

3 Adaptable to different environments

3 Usable as input for migration decisions in Calvin

Challenges

I Dynamic distributed execution modelI All runtimes not known when execution starts





Attribute-Based Access Control (ABAC)

I Evaluate policy rules against attributesI Subject attributesI Resource attributes

I Action attributesI Environment attributes

I Flexible and fine-grained access control

I XACML – XML-based ABAC standard

Who? What? When? Where? Why? How?





Adaptable to Constrained Devices

I Compact message and policy formats

I JSON instead of XMLI Flexibility important

I Local authorization – minimize network trafficI External authorization – minimize storage or processing power needs




Authorization FlowMessage and Policy FormatsSmart MigrationConclusion

Authorization Flow

Policy Administration

Point (PAP)

Policy Enforcement Point (PEP)

Policy Decision Point (PDP)

Policy Information Point

(PIP)

Policy Retrieval Point (PRP)

2. Authorization request

1. Access required

3. Retrieve policies

4a. Evaluate policies

4b. Retrieve additional attributes

Manage policies

5. Authorization decision

User/Application/Actor

6. Access permitted/

denied

Fetch data from different sources





Authorization Request

I Request sent by Policy Enforcement Point to Policy Decision Pointto check if access should be granted to an actor

1 {

2 "subject": {

3 "first_name": "Tomas",

4 "last_name": "Nilsson",

5 "actor_signer": "Ericsson"

6 },

7 "action": {

8 "requires": ["runtime", "calvinsys.events.timer"]

9 },

10 "resource": {

11 "node_id": "a77c0687-dce8-496f-8d81-571333be6116"

12 }

13 }





Authorization Response

I Response from Policy Decision Point to Policy Enforcement Point

I Contains authorization decision and constraints under which thedecision is valid

1 {

2 "decision": "permit",

3 "obligations": [

4 {

5 "id": "time_range",

6 "attributes": {

7 "start_time": "09:00",

8 "end_time": "17:00"

9 }

10 }

11 ]

12 }





Find Matching Policies

I Use policy target to determine to which requests a policy applies

Examples:

I "first name" must be "Tomas" or "Gustav":

{"first_name": ["Tomas", "Gustav"]}

I "email" must end with "@ericsson.com":

{"email": ".*@ericsson.com"}





Evaluate Policies

I Evaluate complete policy if policy target matches the request

I Rules with conditions are evaluated to get a policy decisionI The following functions can be used in a condition:

I ==, <=, >=, !=, AND, OR

I Combining algorithms are used to combine decisions if multiplepolicies match the request

I Permit overridesI Deny overrides





Evaluate Policies

1 {

2 "condition": {

3 "function": "and",

4 "attributes": [

5 {

6 "function": "equal",

7 "attributes": ["attr:resource:address.country",

8 ["SE", "DK"]]

9 },

10 {

11 "function": "greater_than_or_equal",

12 "attributes": ["attr:environment:current_date",

13 "2016-03-04"]

14 }

15 ]

16 }

17 }


xxxxx yyyyy zzzzz..

Payload SignatureHeader




JSON Web Token for External Authorization

I Signed JSON Web Tokens (JWT) are used to secure theinformation exchange when the Policy Decision Point is external

Header:

{

"typ": "JWT",

"alg": "ES256"

}

I ES256 = Elliptic Curve Digital Signature Algorithm using theSHA-256 hash algorithm


xxxxx yyyyy zzzzz..







Payload:

{

"iss": "ID of runtime that creates JWT",

"sub": "ID of actor that the response applies to",

"aud": "ID of runtime to which the JWT is intended",

"iat": "the time at which the JWT was issued",

"exp": "the expiration time for the JWT",

"response": "the authorization response"

}


xxxxx yyyyy zzzzz..







Signature:

I The digital signature of the concatenation of the encoded headerand the encoded payload (separated by ’.’)

I Signed using the private key of the runtime that creates the JWT


Policy Decision

Point

1. Access Denied for Camera, Runtime 1

at 17:00

Camera

Runtime 2 (RT2)

Camera

PDP PDP

Runtime 1 (RT1)(uses PDP on RT2)




Smart Migration


Policy Decision

Point


at 17:00

Camera

Possible migration destinations:

RT2 (PDP on RT2)RT4 (PDP on RT3)

Runtime 2 (RT2)

Camera

2. Get possible migration destinations

from global storage

PDP PDP





Smart Migration


Policy Decision

Point


at 17:00

Camera



Runtime 2 (RT2)

Camera


from global storage

PDP PDP

3. Authorization search request

Signed by Runtime 1 Runtime 1 (RT1)

(uses PDP on RT2)




Smart Migration


Policy Decision

Point


at 17:00

4. No runtimes where access is permitted

Camera



Runtime 2 (RT2)

Camera


from global storage

PDP PDP

3. Authorization search request

Signed by Runtime 1 Runtime 1 (RT1)

(uses PDP on RT2)




Smart Migration


Camera

Policy Decision

Point

Runtime 3 (RT3)


Camera

PDPPDP


5. New authorization search request

Signed by Runtime 1




Smart Migration


Camera

Policy Decision

Point

6. Access Permitted for Camera, Runtime 4

Signed by Runtime 3

Runtime 3 (RT3)


Camera

PDPPDP



Signed by Runtime 1




Smart Migration


7. Migrate Camera actor to Runtime 4(include access decision)

Camera

Policy Decision

Point

6. Access Permitted for Camera, Runtime 4

Signed by Runtime 3

Signed by Runtime 3

Access Permitted for Camera, Runtime 4

Runtime 3 (RT3)


Camera

PDPPDP



Signed by Runtime 1




Smart Migration





Conclusion

I All aims achievedI The following combination is highly suitable for dynamic

distributed execution models:I Attribute-Based Access Control – enables flexibility and fine-grained

decisionsI JSON-based messages and policies – lightweight and compact


Calvin Runtime

Name:laptop

Camera

Address: Testvägen 1,

Lund, SwedenCalvin Runtime

Name:entrance

Camera


Lund, SwedenCalvin Runtime

Name:secret_room



Available RuntimesApplication and Deployment RequirementsAuthorization Policies

Demo – Available Runtimes


trigger

std.Constant

token

camera

media.IPCamera

trigger image

screen

media.ImageRenderer

image

Name:laptop


Lund, Sweden

Name:laptop




Demo – Application and Deployment Requirements

User attributes:

{

"first_name": "Tomas",

"last_name": "Nilsson",

"age": "24",

"organization": "Ericsson",

"group": "Security"

}





Demo – Authorization Policies

Secret room:

3 Permit camera access if subject belongs to group SecurityI Only between 08:00 and 10:XX

Entrance:

3 Permit camera access if subject belongs to group SecurityI Only between 08:00 and 18:00


authorization aspects of the distributed dataflow-oriented iot framework calvin

Technology