authorization

Authorization

The service uses a role based authorization schema. Before deployment the connection to the security database should be configured in a mongo.properties file. The security database contains two relevant collections:

• applications
• users

Next to that every application database contains one:

• roles

collection. Here the actual rights per role are defined.

Collection: applications

in this collection all applications are stored. Each LAS deployment is considered a separate application. The Service will retrieve the application database credentials here.

Example record:

{ 
  "name" : "cb009Overwatch", 
  "database" : { 
    "username" : "las", 
    "host" : "mdb-001", 
    "password" : "XXXX", 
    "port" : 27017, 
    "database" : "cb009Overwatch" 
  } 
}

• name: the identifier for applications
• database.username: database connection information. Required!
• database.host: database connection information. Required!
• database.password: database connection information. Required!
• database.port: database connection information. Required!
• database.database: database connection information. Required!

Collection: users

Each application can have multiple users. In this collection these are registered together with their roles.

Example record

{ 
  "username" : "cb018Overwatch", 
  "password" : "XXXX", 
  "roles" : [ 
    "cb018Overwatch.user"
  ]
}

• username:
• password:
• roles: The roles applicable to this user. The roles here can written here in two ways: {applicationId}.{role} and {role}. The difference is that the first has given role only available in given application while the second has that role available in all applications.

Collection: roles

Each application database should contain a roles collection describing the rights associated with roles.

Example record(s)

{ 
  "name": "user", 
  "deny": [ 
    { 
      "service": "data", 
      "resource": "trilaterationFitterLayer", 
      "rights": "*" 
    } 
  ], 
  "allow": [ 
    { 
      "service": "data", 
      "resource": "*", 
      "rights": "crd" 
    } 
  ] 
}
{ 
  "name": "admin", 
  "deny": [ ], 
  "allow": [ 
    { 
      "service": "data", 
      "resource": "*", 
      "rights": "*" 
    }, { 
      "service": "proxy", 
      "resource": "*", 
      "rights": "*" 
    } 
  ] 
}

• deny.X: A list of deny rules. Deny rules overrule allow rules
• deny.X.service: Name of the service to deny something for.
• deny.X.resource: Name of the resource to deny something for. Wildcard * allowed
• deny.X.rights: Name of the right to deny. Wildcard * allowed. Possibilities: c, r, u, d (any order and combination)
• allow.Y: A list of allow rules. Deny rules overrule allow rules
• allow.Y.service: Name of the service to allow something for.
• allow.Y.resource: Name of the resource to allow something for. Wildcard * allowed
• allow.Y.rights: Name of the right to allow. Wildcard * allowed. Possibilities: c, r, u, d (any order and combination)

Please note! The rights currently follow CRUD (Create, Read, Update, Delete) semantics and apply these on the aligned HTTP methods:

• Create: POST
• Read: GET
• Update: PUT
• Delete: DELETE