Access Control considerations
Regardless of which layer a user facing service resides in or how many underlying service layers a request passes through, the final form of a request would be in SPARQL. To avoid various services having to implement their own form of permission checking, we propose wrapping a “SPARQL proxy” around the layer 0 database. This wrapper would inspect SPARQL queries submitted and rewrite them based on the user’s permissions, as illustrated in https://openmbee.atlassian.net/wiki/spaces/OPENMBEE/pages/320765953 .
In order to do this, the wrapper must be able to lookup the user’s permissions. An Auth service with the following capabilities can be considered.
Prerequisites:
A mms named graph iri can be mapped to a mms resource that has permissions attached (at minimum project, tag/branch tbd)
requests to SPARQL proxy includes a token that can be passed to Auth service (ex. a token in http Authorization header)
requests without token are anonymous (or can give a token for anon user?)
token can be decrypted with a shared secret (between Auth service and SPARQL proxy) that includes permission info
Auth service capabilities:
by default allow creation of users and groups
handle user login and return a token
consider integration support for institutional SSO in case of mms webapps
for users with the right permissions (ex. admin), modify permissions to mms resources
ex. add write permission to a project for a group or user
set a project public (read access for anonymous users)
given a token (or none for anonymous), return all readable/writable projects for user
in addition can accept a list of projects and return user’s permission for each
token includes permissions info for the user that can be decrypted by SPARQL proxy (for performance reasons), (project id, branch id permission)
what about anonymous user?
Example use case flow:
user (ex. auth service api client) logins with auth service and receives a token
user calls the view service, passing it the token
view service does whatever it needs to do, eventually ending up with some SPARQL, and sends it to SPARQL proxy with the token
SPARQL proxy calls Auth service with the token to get permission info, and rewrites (if needed) the SPARQL and sends it to the db
results from db are passed back to view service and back to user in whatever format/schema the view service api provides
Draft JWT token payload example (using mms4 permissions):
{
"sub": "username|anonymous",
"permissions": {
"orgs": [{
"id": "{orgId}",
"role": "ADMIN|READER|WRITER"
}],
"projects": [{
"id": "{projectId}",
"role": "ADMIN|READER|WRITER",
"branches": [{
"id": "{branchId|tagId}",
"role": "ADMIN|READER|WRITER"
}]
}]
}
}In terms of reading/writing to a model graph, the projects and projects.branches roles would be relevant. For example branch READER would be needed to query from a model graph, branch WRITER would be needed to update a model graph and the project metadata graph. Project WRITER would be needed to create branch.
| ADMIN | WRITER | READER |
|---|---|---|---|
Org | delete org | create project |
|
Project | delete project | create branch|tag | query commits |
Branch|Tag | delete branch | update | query |
Why not have an auth layer on the very top, api gateway style?
This may work if all potential services have rest style endpoints and all permission can be gleaned from the url, but with some of the features of mms projects (mounting other projects), a permissions check still needs to occur on the actual results. (Ex. An endpoint to search for an element in one project may result in elements in mounted projects where the user has no permission to view.) In addition, we’ll like to allow direct SPARQL queries for expert users while maintaining access control. The SPARQL proxy can provide that without letting direct access to the db.