orientdb: OrientDB authorization model can not be used as application level authorization

@lvca I’ve put together a working implementation for token based authentication in orientdb. It isn’t perfect and requires some work to ensure proper security. However, I wanted to share with you so you could, if you wanted, test out whether this type of mechanism is appropriate for OrientDb.

All my changes are in my local repo: https://github.com/emrul/orientdb/commit/c15c979331767e897ecc489d3c390a61766c7b51

Obtaining a token

There is a new endpoint /token/<db_name> that will return an authentication token. In the example below there is a database named ‘TestTokenAuth’ with user ‘emrul@emrul.com’ and password ‘password’: The request parameters conform to the OAuth2 specification

curl --data "grant_type=password&username=emrul@emrul.com&password=password" http://localhost:2480/token/TestTokenAuth

This returns a JSON structure including the access_token and expires_in information. This is consistent with the OAuth2 specification but not complete:

{"@type":"d","@version":0,"access_token":"eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyUmlkIjoiIzU6MyIsImV4cCI6MTQxMDgxOTE5NiwiZGF0YWJhc2VOYW1lIjoiVGVzdFRva2VuQXV0aCIsInN1YiI6ImVtcnVsQGVtcnVsLmNvbSIsImF1ZCI6Ik9yaWVudERiIiwiaXNzIjoiT3JpZW50RGIiLCJqdGkiOiI4N2YxZjIzNy1jMjhmLTRjMjctOWM0Yy05MDQ1MjgyMjgwYTEiLCJpYXQiOjE0MTA4MTkxODZ9.GD2r5Hf1hXSE_0R4BOMjfeZ8y_kBS2ysZvngAPTjjN8","expires_in":10000}

You can copy & paste the access token over at jwt.io, it looks like this:

{
  "userRid": "#5:3",
  "exp": 1410819196,
  "databaseName": "TestTokenAuth",
  "sub": "emrul@emrul.com",
  "aud": "OrientDb",
  "iss": "OrientDb",
  "jti": "87f1f237-c28f-4c27-9c4c-9045282280a1",
  "iat": 1410819186
}

The access token isn’t as I would prefer for a full implementation but contains the minimum needed to demonstrate the functionality.

Using a token for authentication

You pass the token as an bearer token in the Authorisation header. For example:

curl --header "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyUmlkIjoiIzU6MyIsImV4cCI6MTQxMDgxNzUxOCwiZGF0YWJhc2VOYW1lIjoiVGVzdFRva2VuQXV0aCIsInN1YiI6ImVtcnVsQGVtcnVsLmNvbSIsImF1ZCI6Ik9yaWVudERiIiwiaXNzIjoiT3JpZW50RGIiLCJqdGkiOiI2YWIzOTJlNy04ZWEzLTRmZmItYjhmMS1lZTlmMTVmYjY5ZDkiLCJpYXQiOjE0MTA4MTc1MDh9.LAT7MHlhihMkKwC_9dM1r3HFAfkj4BPngXzIEVxTlUg" "http://localhost:2480/query/TestTokenAuth/sql/select%20*%20from%20AClass"

Current implementation notes

• The signing key is currently stored in the orientdb-server-config.xml as a Base64 encoded property named ‘oauth2.secretkey’ - like the root password, this would need to be changed for each implementation but a better approach would be to manage these keys in the database (perhaps on a per-database level). In my implementation the secret key has been set to ‘tokenkey’
• Signature verification is currently performed twice (once in OSecurityShared and once in OServerCommandAuthenticatedDbAbstract) - this will need to be changed.
• OSecurityShared has a new getUser method that loads the user directly by rid when authenticating by token - maybe this is a little faster than authentication by username.
• The current implementation does not disable HTTP Basic auth (all of that code is still there and should work as it did before)
• Expiry time is hard-coded (10 minutes). This should be configurable
• I used Nimbus-JWT but I think it would be better to have our own token signing/verification classes rather than rely on this dependency.
• No tests 😦

Summary

• OrientDb is now an OAuth2 resource server. With a little more work OrientDb can be a full OAuth2 provider.
• It is possible to enable Single-sign-on type systems because the token does not store or require the user password. To do this we would support ‘grant_types’ other than password.
• We could make user of the OAuth2 ‘scopes’ field to store a list of roles. I believe this would get us to the externally managed accounts that @rajohn96 mentioned.

Any thoughts are welcome.