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