ArcadeData / arcadedb

ArcadeDB Multi-Model Database, one DBMS that supports SQL, Cypher, Gremlin, HTTP/JSON, MongoDB and Redis. ArcadeDB is a conceptual fork of OrientDB, the first Multi-Model DBMS. ArcadeDB supports Vector Embeddings.
https://arcadedb.com
Apache License 2.0
482 stars 59 forks source link

Get a authentification token instead of allowing only the login/password for queries #1691

Open ExtReMLapin opened 4 weeks ago

ExtReMLapin commented 4 weeks ago

Hello,

At the office, we're working on an application and ArcadeDB is the only database we want to rely on.

As we need a JWT token, we decided to use the ArcadeDB user system instead of using LDAP or ActiveDirectory.

Login and registration endpoints works correctly as it execute user registration using root account and login using user provided creditentials.

Issue is that, after being connected, the client will execute a query on endpoint /do_something JWT token will report user as being user "Ben" but as it need to executes queries in it's name (Because if the database visibility/rights system is in place in arcadeDB, no need to re-code it on our side) we need to send a query using the user password.

And this is where we're stuck, we CANNOT (should not, actually) store the user password in the JWT temporary database.

However, if ArcadeDB was returning a token for authentification, we could with no much worry store this temporary token in the JWT database and the user password would be safe.

TL;DR :

In our application user system is literally using ArcadeDB user's accounts system, which means that for each action on the database that is executed by the application need to be done in the user's name, which requires the username/password to be saved after login, during the whole token time of life.

Adding a token system for authentification would help a lot.

We only use the HTTP/REST API.

Thanks.

ExtReMLapin commented 4 weeks ago

As a clarification, we could do all actions using "root" account, but we would need to implement in a quite few places "Btw does [cur user] has access to this database ?" check.

lvca commented 3 weeks ago

You could execute a command with theuser/password (like a select 1), save the session token in the response header as arcadedb-session-id, and send back to further requests.

If the token is present and the session is still valid, the user and password are not needed.

ExtReMLapin commented 3 weeks ago

Thaks for the answer, looks like i should have ctrl-f’ed « session » and not « token ».

will implement today and get back here with my solution

ExtReMLapin commented 3 weeks ago

So I have a try with POSTMAN, and

  1. When executing a simple query (for example SELECT 1) it doesn't return me a transaction/session id, the only way to get a transaction ID is to use the /begin endpoint.
  2. So I decided to give a try with the /begin endpoint but it still waits for a login:password.

I have a set of unit tests in python for arcadedb, including transactions (begin, commit, rollback, etc).

Since then, we always sent the root:password in our arcadedb requests, in the code that sends extra headers, we always sent the root:password,

After your message, I added a check to omit the login:password if the header arcadedb-session-id was there and it ALWAYS return a code 401.

Also in the documentation example even with the transaction id, login:password is sent.

curl -I -X POST http://localhost:2480/api/v1/commit/school \
       -H "arcadedb-session-id: AS-ee056170-dc9b-4956-8d71-d7cfa01900d4" \
       --user root:arcadedb-password
lvca commented 3 weeks ago

I guess we inherit the "session" name from OrientDB, but it's more a transaction id than a session id. ArcadeDB is basically stateless until you begin a transaction.

Ok, I see we'd need a /login endpoint that gets the credentials and returns a session token that can be used by all the commands to bypass authentication.

This could also speed up commands in general because the credentials don't need to be checked every time.

ExtReMLapin commented 3 weeks ago

Thanks for the quick update.

Right now we opted for a full "root" interractions policy, but i'll be happy to move to a safer arcade-token as soon as it's ready.