Extend Server Security

[lvca]

SUMMARY

Status: Released in v21.10.1.
Progress: Design 100% -> Development & Unit Tests 100% -> Integration Tests 100%
Currently Assigned: @lvca
ETA: 5 days
From: Ideas [#44]
To: Issues [#72]

---

ArcadeDB supports super-simple security for users in a server. Example of security.json file:

{
  "users": {
    "root": {
      "databases": [],
      "password": "PBKDF2WithHmacSHA256$65536$esd1hjs=...",
       "name": "root",
       "databaseBlackList": true
    },
    "elon": {
      "databases": ["Universe"],
      "password": "PBKDF2WithHmacSHA256$65536$lYhGpkO4Tgu53hBc3D...=",
      "name": "elon",
      "databaseBlackList": false
    }
  }
}

Below you can find the proposal to improve the Server Side security.

Support for access mode

Apart from the list of databases, it would be nice to extend the databases property from an array into a map with the access mode with the following values: readOnly and readWrite. Example:

"elon": {
  "databases": {
    "Universe": {
      "access": "readOnly",
    }
  },
}

Profile access to types for CRUD operations

We could extend the database map (see above) by adding the types map for profiling at the type level granularity:

"elon": {
  "databases": {
    "Universe": {
      "access": "readWrite",
      "types": {
        "Post": {
          "access": "r",
          "limit": 10
        },
        "Comment": {
          "access": "r",
          "limit": 100,
          "readTimeout": 5000
        },
        "Note": {
          "access": "crud"
        }
      }
    }
  },
}

The access property (case insensitive) can express the permission by using:

• 'c' to create new records for the type
• 'r' to read records for the type
• 'u' to update records for the type
• 'd' to delete records for the type

The property limit, if present, tells to cut off resultsets larger than the value in this field. This is useful to avoid some users can stress the database by returning huge resultsets.

The property readTimeout, if present, limits the query execution to the timeout expresses in milliseconds.

Support for group

Instead of creating the profiling for each user, it would be nice having the option to configure groups and assign users to one or more groups. Example

{
  "users": {
    "elon": {
      "groups": ["mobileUsers"]
    }
  },
  "groups": {
    "mobileUsers" : {
      
    }
  },
}

Add version for further compatibility

Adding a version allows the server to support the evolution of the security.json file. Example:

{
  "users": {},
  "groups": {},
  "version": 1
}

[PhantomYdn]

Sounds interesting, but will security settings be modifiable as ArcadeDB documents? Or it's going to be a static configuration?

[lvca]

Good question. There will be Java API to change the security. If you're using the server embedded you can use it, so it will be dynamic. We could also provide HTTP API for that, but we should pay attention to the security.

[PhantomYdn]

Any opportunity to mimic OrientDB there? It's pretty useful to be able to refer from a datamodel to a user which is accessing data.
At least you can have some abstraction there: SecurityCredentialsProvider. So if needed - it can be extended to be able to get model from a current DB or any other source.

[lvca]

Writing users, permissions, and metadata in every single record (record-level security) will not be supported in ArcadeDB. The reason is easy and pretty strong: it is not efficient, slow, and error-prone. Overriding the security credential policy is already possible with:

server.getSecurity().setCredentialsValidator( new DefaultCredentialsValidator(){
  @Override
  public void validateCredentials(final String userName, final String userPassword) throws ServerSecurityException {
    if( userPassword.equals("12345678")
      throw new ServerSecurityException("Guess who was not attending security lesson!");
  }
});

[PhantomYdn]

@lvca , I can't here agree with you. My logic is the following: in real-life applications row-level security is definitely needed. So there are two ways where it can be implemented: either on the application level or the DB level. Do that on the application level is not a good option, because, it's error-prone and inefficient from a performance perspective. And only on DB-level implementation, there might be a good standard for all apps which use that DB on how to do row-level security. And once it's DB-level: there are no limits in making row-level security as efficient as needed.

Btw, I'm not saying about ORestricted, but rather about OSecurityPolicy. I think it's already some kind of standard between DBs: PostgreSQL has a very similar implementation https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html. And it's very efficient for multi-tenant applications.

[lvca]

@PhantomYdn do you have a real use case of a user that needed that level of security and completely delegated it to the database without any application code?

I know it's a nice feature to have, but AFAIK, all OrientDB users that use it were trying to manage multi-tenancy. And record level security is a very inefficient way to do that.

That's why I'm more focused on providing an efficient multi-tenancy solution.

And after all, as soon as the callback is documented, anybody can build their own plugin, so nothing stops you or other developers to write such a plugin.

[PhantomYdn]

I have such usecases in every single our project. Just few examples:

• Lead generation platform. Lead's owner wants to be able to manage who else from the registered users can see that lead.
• Inner platform communication. Users can send messages to each other. So message should be visible only to limited set of users who are in that particular conversation.
• Real-estate offers management system. Particular offer should be visible only to limited set of users: more over this set of user depends on a life-cycle stage of that offer. Just-created should be visible only to author. After submission it should be visible to moderators. After publication it should be visible to everyone.

In all these cases we really want to be able to support on DB level. Why? Because otherwise any user can do something like select * from Offer and get access to all DB.

I think that there is more high-level problem. Should a user be just to connect to DB or it also can be treated as application-level user. What's interesting here, that all simple apps (like WordPress) tends to use only one user per DB and has their own users on app level, but all more or less enterprise apps use DB users or at least DB users as a reflection of required app rights.

Yes - if callbacks and other hooks will be there - potentially it's an option. But, btw, on this particular case deeper integration to SQL parser is needed, because security policy translated into adjusted SQL expression.

[lvca]

Issue #72 has been created from this discussion, so any further updates and discussions should follow up on the issue instead of this thread.