README.md

Authorization service

authorization describes how and provides resources to include authorization in a custom mu-semtech project

Running the authorization microservice

Add it to a mu-semtech project

To add authorization to a mu-semtech project you would need to do the following:

• add the missing, if any, prefixes to config/resources/repository.lisp
• make sure that all resources are added or augmented in your domain.lisp file
• [optional] add the authorization model triples from data/toLoad/basic-access-tokens.ttl to your database, if you choose to use custom triples make sure that you understand the model completely
• [optional] augment the basic authorization triples with specific triples for your application (ie perhaps you need extra tokens like approve or aggregate
• [optional] the ember-mu-authorization addon will provide your front end with a quick and customizable authorization management console
• [optional] add a triple for each artifact on which authorization has to be enforced, this triple will be <artifact-id> a auth:Authenticatable

Data

To work authorization will expect certain basic triples to be present in the triple store. You can add/alter them manually or you can include the turtle file that you find in data/toLoad/basic-access-tokens.ttl. This turtle file defines the 4 basic access tokens types (show, update, create, delete), a group of basic access tokens, a grant that allows show/update/create/delete rights on that group and an administrator user group that has these rights. The administrator group itself is also an authenticatable but there are no rights defined on this group.

adding authorization in a docker compose setup

This is an example docker-compose.yml file that includes the authorization service

identifier:
  image: semtech/mu-identifier:1.0.0
  ports:
    - "80:80"
  links:
    - dispatcher:dispatcher
dispatcher:
  image: semtech/mu-dispatcher:1.0.1
  volumes:
    - ./config/dispatcher:/config
  links:
    - resource:resource
database:
  image: tenforce/virtuoso:1.0.0-virtuoso7.2.2
  environment:
    SPARQL_UPDATE: "true"
    DEFAULT_GRAPH: http://mu.semte.ch/application
    DBA_PASSWORD: dba
  ports:
    - "8890:8890"
  volumes:
    - ./data/db:/data
authorization:
  image: semtech/authorization
  links:
    - database:database

Run the authorization service as a microservice

To run this authorization service as a single docker container please do:

docker run --name mu-authorization \
       -p 80:80
       --link database:database
       -d semtech/authorization

The basic authorization triples still have to be added to the triple store.

The authorization query

The following sparql query will allow your microservice to test whether the currently active user has (a) token(s) on the passed artifact(s)(group).

display query here

the authorization model

prefixes

auth: http://mu.semte.ch/vocabularies/authorization/
foaf: http://xmlns.com/foaf/0.1/
mu: http://mu.semte.ch/vocabularies/core/
dct: http://purl.org/dc/terms/

entities

The authorization model consists of the following entities:

entity	short description	type	properties [arity] name predicate
user	A user is a real person who will be using the system.	foaf:Person	[1] uuid mu:uuid [1] name foaf:name [*] grant auth:hasRight
userGroup	A user group can contain none, one or multiple users and none, one or multiple other user groups which do not contain it.	foaf:Group	[1] uuid mu:uuid [1] name foaf:name [*] user inverse auth:belongsToAccessGroup [*] subgroup inverse auth:belongsToGroup [*] parentgroup auth:belongsToGroup [*] grant auth:hasRight
authenticatable	An authenticatable represents an object or a collection of objects on which a user can (himself or through rights granted by a group to which he belongs) have access rights. An authenticatable can belong to another authenticatable.	auth:Authenticatable	[1] uuid mu:uuid [1] title dct:title [*] group auth:belongsToArtifactGroup
access token	An access token represents an abstract type of authorization that can be granted to a user. There are 4 "standard" access tokens: create delete show update . A microservice can offer support for different types of access tokens.	auth:AccessToken	[1] uuid mu:uuid [1] title dct:title [1] description dct:description
grant	A grant represents a link between on one hand one or more access tokens an on the other hand one or more authenticatables.	auth:Grant	[1] uuid mu:uuid [*] accessToken auth:hasToken [*] authenticatable auth:operatesOn