Generation and storage

Depends on the agent that uses the PKG, the process to generate PKG are different. In total, there are three manners for the generation of PKGs: for Border Router, for administrator and for non-administrator. The PKGs are respectively stored in different maps in Security Manager according to the agents that they work for.

PKG for Border Router

The PKG for a Border Router contains all the information that belong to its client, which consists of three parts: named graph of the client, deductions named graph of the client and NG-Basic. In total, there are three steps of the PKG generation for a Border Router. Taking the BorderRouter1 in Fig. 5.7 as example, the PKG generation for a Border Router has four steps:

[1] The Named Graph Manager checks with System KG to obtain the clientID correspond- ing to this Border Router. The BorderRouter1 belongs to client0001.

110 Fine-grained access control for the Web of Things [2] The Named Graph Manager generates the URLs of demanded named graphs. In this

case, two URLs are obtained:

• "batmp.cedint.upm.es/BATOnt/client0001" • "batmp.cedint.upm.es/BATOnt/inf/client0001"

[3] The PKG Generator combines the following three named graphs together as PKG- BorderRouter1 and put entry <BorderRouter1, PKG-BorderRouter1> in the map BorderRouterID-PKG:

• "batmp.cedint.upm.es/BATOnt/client0001" • "batmp.cedint.upm.es/BATOnt/inf/client0001" • NG-Basic

[4] Put a new entry <BorderRouter1, client0001> to the map Token/BorderRouterID- ClientID.

PKG for administrator

As an administrator has the right to change all the information of human resource and infrastructures of his client, the PKG for an administrator contains all the information that belong to his client. The PKG consist of three named graphs: NG-Basic, named graph of the client and the deductions named graph of this client. In Fig. 5.7, userA is the administrator. The PKG generation for an administrator has six steps:

[1] The Named Graph Manager queries the System KG and obtains the corresponding clientID of the user, which is client0001 in this case.

[2] By knowing the clientID, the URLs of the two demanded named graphs are generated: • "batmp.cedint.upm.es/BATOnt/client0001"

• "batmp.cedint.upm.es/BATOnt/inf/client0001"

[3] The PKG Generator combines the following three named graphs together as PKG- userA:

• "batmp.cedint.upm.es/BATOnt/client0001" • "batmp.cedint.upm.es/BATOnt/inf/client0001" • NG-Basic

5.5 PKG management 111

[4] Put a new entry <Token-1, PKG-userA> in the map Token-AdminPKG.

[5] Put a new entry <Token-1, client0001> to the map Token/BorderRouterID-ClientID [6] Put new entry <Token-1, 1451637900000> to the map Token-TimeStamp.

PKG for non-administrator user

For an non-administrator user, the PKG should be restricted to the informations that is related to the user in some way. In the platform, from the perspective of control, the relevance of an entity to a user is decided by its relevance to the parameters that the user has permission to access. As a result, the PKG is generated by searching all the entities that have relationship with the parameters, either direct or indirect. Meanwhile, for non-administrators, apart from the PKG, a Writable Parameter List (WPL) should also be retrieved to disclose all the parameters that the user is authorized to modify.

The PKG generation for a non-administrator has six steps:

[1] The Named Graph Manager queries the System KG and obtains the corresponding clientID of the user.

[2] By knowing the clientID, the URLs of demanded named graphs are generated, which are:

• "batmp.cedint.upm.es/BATOnt/client0001" • "batmp.cedint.upm.es/BATOnt/inf/client0001"

[3] The PKG Generator combines the named graphs "batmp.cedint.upm.es/BATOnt/client0001", "batmp.cedint.upm.es/BATOnt/inf/client0001" and NG-Basic together as a new named graph, denoted as NG-client

[4] Apply the CONSTRUCT SPARQL query shown in Listing 5.3 against NG-client, where the text USER_ID refers to the ID of the user.

[5] Generate the WPL Luser by applying the SPARQL query in Listing 5.4, where the text

USER_ID refers to the ID of the user. In this case, by replacing USER_ID with userB,

the list Luser-userB is generated for Token-2.

[6] After having obtained PKG-userB and list Luser-userB, the entries are added to the

corresponding maps:

112 Fine-grained access control for the Web of Things • Entry <Token-2, userB> to map Token-NonAdminUserID

• Entry <Token-2, client0001> to map Token/BorderRouterID-ClientID

• Entry <Token-2,Luser-userB> to map Token-WPL

5.5 PKG management 113 CONSTRUCT { ?u ?p ?param. ?u ?x ?y. ?y ?z ?w. ?param ?p1 ?o1. ?o2 ?p2 ?param. ?o3 ?p3 ?o2. ?o4 ?p4 ?o3. ?o2 ?p5 ?o5. ?o5 ?p6 ?o6. ?o6 ?p7 ?o7. ?o8 ?p8 ?u. } WHERE {

?u rdf:type bat:User.

?param rdf:type bat:Parameter.

?u bat:id "USER_ID"^^xsd:string. ?u ?p ?param.

OPTIONAL {?param ?p1 ?o1. ?u ?x ?y.

OPTIONAL {?y ?z ?w.}} OPTIONAL {?o2 ?p2 ?param.

FILTER NOT EXISTS {?o2 rdf:type bat:User}

OPTIONAL {?o3 ?p3 ?o2.

FILTER NOT EXISTS {?o3 rdf:type bat:User}

OPTIONAL {?o4 ?p4 ?o3.}}} OPTIONAL {?o2 ?p5 ?o5.

FILTER NOT EXISTS {?o5 rdf:type bat:Parameter}

OPTIONAL {?o5 ?p6 ?o6.

FILTER NOT EXISTS {?o6 rdf:type bat:Parameter}

OPTIONAL {?o6 ?p7 ?o7.}}} OPTIONAL {?o8 ?p8 ?u.}} ;

114 Fine-grained access control for the Web of Things

SELECT ?id WHERE {

?p rdf:type bat:Parameter.

?u rdf:type bat:User.

?p bat:id ?id.

?u bat:id "USER_ID"^^xsd:string.

?u bat:hasWritePermission ?p

}

Listing 5.4 SPARQL query for all the parameters that the user can modify