Page Comparison

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 MMS 5 Architecture .

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.

...

• 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:

1. user (ex. auth service api client) logins with auth service and receives a token

2. user calls the view service, passing it the token

3. view service does whatever it needs to do, eventually ending up with some SPARQL, and sends it to SPARQL proxy with the token

4. SPARQL proxy calls Auth service with the token to get permission info, and rewrites (if needed) the SPARQL and sends it to the db

5. 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.

Why not have an auth layer on the very top, api gateway style?

...