Partitioned graphs

This tutorial explains step-by-step how to create partitioned graphs using the Record Level Security feature introduced in OrientDB 1.2.0. This feature is so powerful we can totally separate database’s records as sand-boxes where each “Restricted” records can’t be accessed by non authorized users. This tutorial demonstrates this sand-boxes works well also with the GraphDB API and the TinkerPop stack. Partitioning graphs allows to build real Multi-tenant applications in a breeze.

Requirements:

  • OrientDB 1.2.0-SNAPSHOT or higher
  • TinkerPop Blueprints 2.2.0 or higher.

Create a new empty graph database

First open the console of the GraphDB Edition and create the new database “blog” of type “graph” against the local file-system:

  1. $ cd $ORIENTDB_HOME/bin
  2. $ console.sh
  3. OrientDB console v.1.2.0-SNAPSHOT www.orientechnologies.com
  4. Type 'help' to display all the commands supported.
  6. Installing extensions for GREMLIN language v.2.2.0-SNAPSHOT
  8. orientdb> CREATE DATABASE local::../databases/blog admin admin local graph
  9. Creating database [local:../databases/blog] using the storage type [local]...
  10. Database created successfully.
  12. Current database is: local:../databases/blog

Enable graph partitioning

Now turn on partitioning against graph by letting classes V (Vertex) and E (Edge) to extend the éORestricted* class. In this way any access to Vertex and Edge instances can be restricted:

  1. ALTER CLASS V superclass orestricted
  3. Class updated successfully
  1. ALTER CLASS E superclass orestricted
  3. Class updated successfully

Create 2 users

Now let’s go creating 2 users: “luca” and “steve”. First ask the current roles in database to know the “writer” role’s rid:

  1. SELECT FROM orole
  3.  ---+------+--------+------+---------------------------------------------------------------+----------------
  4.   # | RID  | name   | mode | rules                                                         | inheritedRole
  5.  ---+------+--------+------+---------------------------------------------------------------+-----------------
  6.   0 | #4:0 | admin  | 1    | {}                                                            | null
  7.   1 | #4:1 | reader | 0    | {database=2, database.schema=2, database.cluster.internal=2,  | null
  8.     |      |        |      | {database.cluster.orole=2, database.cluster.ouser=2,          |
  9.     |         |        |      | database.class.*=2, database.cluster.*=2, database.command=2, |
  10.     |       |        |      | database.hook.record=2                                        |
  11.   2 | #4:2 |writer  | 0    | {database=2, database.schema=7, database.cluster.internal=2,  | null
  12.     |      |        |      |  database.cluster.orole=2, database.cluster.ouser=2,          |
  13.     |      |        |      |  database.class.*=15, database.cluster.*=15,                  |
  14.     |      |        |      |  database.command=15, database.hook.record=15}                |
  15.  ---+------+--------+------+---------------------------------------------------------------+------------------
  17. 3 item(s) found. Query executed in 0.045 sec(s).

Found it, it’s the #4:2. Not create 2 users with as first role #4:2 (writer):

  1. INSERT INTO ouser SET name = 'luca', status = 'ACTIVE', password = 'luca', roles = [#4:2]
  3. Inserted record 'OUser#5:4{name:luca,password:{SHA-256}D70F47790F689414789EEFF231703429C7F88A10210775906460EDBF38589D90,roles:[1]} v1' in 0,001000 sec(s).
  5. INSERT INTO ouser SET name = 'steve', status = 'ACTIVE', password = 'steve', roles = [#4:2]
  7. Inserted record 'OUser#5:3{name:steve,password:{SHA-256}F148389D080CFE85952998A8A367E2F7EAF35F2D72D2599A5B0412FE4094D65C,roles:[1]} v1' in 0,001000 sec(s).

Create a simple graph as user ‘Luca’

Now it’s time to disconnect and reconnect to the blog database using the new “luca” user:

  1. DISCONNECT
  3. Disconnecting from the database [blog]...OK
  1. CONNECT local:../databases/blog luca luca
  2. Connecting to database [local:../databases/blog] with user 'luca'...OK

Now create 2 vertices: a Restaurant and a Pizza:

  1. CREATE VERTEX SET label = 'food', name = 'Pizza'
  3. Created vertex 'V#9:0{label:food,name:Pizza,_allow:[1]} v0' in 0,001000 sec(s).
  1. CREATE VERTEX SET label = 'restaurant', name = "Dante's Pizza"
  3. Created vertex 'V#9:1{label:restaurant,name:Dante's Pizza,_allow:[1]} v0' in 0,000000 sec(s).

Now connect these 2 vertices with an edge labelled “menu”:

  1. CREATE EDGE FROM #9:0 TO #9:1 SET label = 'menu'
  3. Created edge '[E#10:0{out:#9:0,in:#9:1,label:menu,_allow:[1]} v1]' in 0,003000 sec(s).

To check if everything is ok execute a select against vertices:

  1. SELECT FROM V
  3.  ---+------+------------+---------------+-----------------
  4.   # | RID  | label      | name          | _allow | out
  5.  ---+------+------------+---------------+--------+--------
  6.   0 | #9:0 | food       | Pizza         | [1]    | [1]
  7.   1 | #9:1 | restaurant | Dante's Pizza | [1]    | null
  8.  ---+------+------------+---------------+--------+--------
  10.  2 item(s) found. Query executed in 0.034 sec(s).

Create a simple graph as user ‘Steve’

Now let’s connect to the database using the ‘Steve’ user and check if there are vertices:

  1. DISCONNECT
  3. Disconnecting from the database [blog]...OK
  5. CONNECT local:../databases/blog steve steve
  6. Connecting to database [local:../databases/blog] with user 'steve'...OK
  8. SELECT FROM V
  10. 0 item(s) found. Query executed in 0.0 sec(s).

Ok, no vertices found. Try to create something:

  1. CREATE VERTEX SET label = 'car', name = 'Ferrari Modena'
  3.  Created vertex 'V#9:2{label:car,name:Ferrari Modena,_allow:[1]} v0' in 0,000000 sec(s).
  5. CREATE VERTEX SET label = 'driver', name = 'steve'
  7. Created vertex 'V#9:3{label:driver,name:steve,_allow:[1]} v0' in 0,000000 sec(s).
  9. CREATE EDGE FROM #9:2 TO #9:3 SET label = 'drive'
  11. Created edge '[E#10:1{out:#9:2,in:#9:3,label:drive,_allow:[1]} v1]' in 0,002000 sec(s).

Now check the graph just created:

  1. SELECT FROM V
  3.  ---+------+--------+----------------+--------+------
  4.   # | RID  | label  | name           | _allow | out
  5.  ---+------+--------+----------------+--------+------
  6.   0 | #9:2 | car    | Ferrari Modena | [1]    | [1]
  7.   1 | #9:3 | driver | steve          | [1]    | null 
  8.  ---+------+--------+----------------+--------+------
  10. 2 item(s) found. Query executed in 0.034 sec(s).

The “Steve” user doesn’t see the vertices and edges creates by other users!

What happen if we try to connect 2 vertices of different users?

  1. CREATE EDGE FROM #9:2 TO #9:0 SET label = 'security-test'
  3. Error: com.orientechnologies.orient.core.exception.OCommandExecutionException: Error on execution of command: OCommandSQL [text=create edge from #9:2 to #9:0 set label = 'security-test']
  4. Error: java.lang.IllegalArgumentException: Source vertex '#9:0' does not exist

The partition is totally isolated and OrientDB thinks the vertex doesn’t exist while it’s present, but invisible to the current user.

TinkerPop Stack

Record Level Security feature is very powerful because acts at low level inside the OrientDB engine. This is why everything works like a charm, even the TinkerPop stack.

Now try to display all the vertices and edges using Gremlin:

  1. gremlin g.V
  3. [v[#9:2], v[#9:3]]
  5. Script executed in 0,448000 sec(s).
  7. gremlin g.E
  9. e[#10:1][#9:2-drive->#9:3]
  11. Script executed in 0,123000 sec(s).

The same is using other technologies that use the !TinkerPop Blueprints: TinkerPop Rexter, TinkerPop Pipes, TinkerPop Furnace, TinkerPop Frames and ThinkAurelius Faunus.