Structure of authorizations

[rmader]

We now have autherization objects when doing a login, but we don't yet settled on a structure how to write the individual rights.

Here a short proposal:

• We have general user roles (like admin/user/premium user...)
• These user roles define a set of rights, but for each user, we can overwrite them if needed
• for each class, whos name is a key, we have an object with attributes

A little example of how authorization.json could look like:

{ userRole:user : { AccountServlet: { ... }, SearchServlet : { maxQuerySize: 300 }, ... } user:bla@blubb.de : { userRole : user, SearchServlet : { maxQuerySize: 500 } } }

So each user has a role which defines basic standard rights and then has individual rights. The rights for each servlet can be structured as the servlet needs it.

Each servlet can then query for rights.get(this.getClass().getSimpleName()) and get's a object with the fields it uses. For example: the SearchServlet gets a JSONObject:

{ maxQuerySize: 500 }

What do you think?

[Orbiter]

right, having roles and assignment in authorization.json is the 'glue' for our rights managament.

I suggest the following general roles:

• Administrator: is allowed to do everything (currently: localhost access), including assignment of rights
• Moderator: has rights to use all services and to assign user rights, up to moderation rights
• Service Manager: has right to use all services and change service level settings, also for specific users
• User with Identity: has rights as assigned
• Anonymous user: has lowest rights as everybody has. This can be managed like a special user with ‘anonymous’ identity.

These must be assigned in the enum class APIServiceLevel as token.

Then one of these roles (only one!) must be assigned to each user. Aside of those roles the user may get assigned specific volume-access grants on service level, as @treba123 already suggested.

The remaining 'handle' to know if one is allowed to access a servlet is the method APIHandler.getDefaultServiceLevel() (for anonymous users) and APIHandler.getCustomServiceLevel(Authorization httpaccount) for authenticated users and the authorization object carries the information for i.e. volume-specific information.

The Authorization object also provides the Accounting object which contains counters to fullfill volume-related authorizations.

[rmader]

Alright, that makes sense. I'll try to use that this way and write a little howto afterwards

[rmader]

I'm actually still thinking about how to make this the most easiest for users and programmers. In my mind, it should be as easy and unconfusing as possible, so for somebody who writes a servlet everything to do to have a propper rights management should be as selfexplaining as possible.

Some ideas:

• each servlet can specify its own keys it wants to use (e.g. allowed_to_download)
• for each user role, a default value has to be specified (e.g. for User allowed_to_download=true, Anonymous user allowed_to_download=false.
• within serviceImpl, checking for a value should be as easy as something like rights.get('allowed_to_download', false) to check if the user is allowed to do something or not.
• In my oppinion, this should NOT be directly related with the user role. The rights of the user should be inherited from the user role, but if they got overwritten for some reason (to be able to create fine grained user rights), the servlet author should not have to deal with it.

[rmader]

I'll create a PR later the day, as discussion base

[rmader]

I'm currently more and more hitting the limitations of our current JsonTray 'database'. Would it be ok to include a simple embedded sql database? That would save us lots of work, make it easier to do things save and performant.

[rmader]

@Orbiter there's actually lot's of questions in my head about the structure you already half way created. I can only guess what you mean by it and how you want to structure it. Just found out you created something called ClientService. What is it exacly meant to be? And is APIServiceLevel something different than a user role? And how exactly are they meant to be used? Does every user role just get's a service level assigned? Or does every servlet decide on each own which user (role) it assigns which service level, based on their rights?

The question which again comes up for me at this point is: does it make sense if I try to finish something you already have a somewhat precise idea how it should be done?

Because if I'd done it just by myself, I would have had a solution ready, but it would barely have anything in common with yours (i would have modeled it more like php projects like wordpress do it, centered around an embedded sql database).

Now I'm trying to come up with solutions that fits into what's already there. But every now and then I find out there's already something which is meant to do something, but I first need alot of time to understand it, adjust my solution...repeat.

I'd like to suggest the follwing for the future:

• one person does job for one specific, capsulated topic (e.g. authentication, authorization or accounting)
• if one person does something that has to be finished by another, there has to be some kind of plan how everything is meant to interact. Not only plain sourcecode.

I'm sorry, I know you have alot of other things to do, but here I'm really struggling to make something useful out of this. Until we have a solution, I'll continue working on other things.

[rmader]

@Orbiter About the APIServiceLevel again: is it meant in the way that getDefaultServiceLevel() specifies the minimum required service level? And that, if getCustomServiceLevel(Authorization rights) returns a lower APIServiceLevel, we should return a 401 message? Something like this in AbstractAPIHandler:

if(getCustomServiceLevel(authorization).isSmallerThan(serviceLevel)){
            response.sendError(401, "Unauthorized");
            return;
        }

In the sense that in serviceImpl() I can already assume that the user has the corresponding rights?

[rmader]

Alright, after having a call with Michael yesterday, things are more clear for me. Here a new proposel I will try to implement next week:

1. BaseUserRole (BUR)

APIAccessLevel will be renamed to BaseUserRole. These are user roles that are hardcoded into the java code and their main purpose is to have an easy and solid mechanism to limit access.

This is mostly about the differences between admins, users and anymous users and does not allow for fine grained control.

For each BUR we will have templates for rights they have for each servlet. This is explained in 4.

2. Real user roles

Apart from the hardcoded BUR, we have the real user roles. These are freely configurable and we can have as many of them as we need. Each user role will have a parent from which it inherits rights. That can be a BUR or some other user role. But the root of each tree of user roles always must be a BUR, so we can always resolve one for each user role. Their main purpose is to be able to override rights inherited from the templates

3. Users

Each user has one user role (maybe we can later also assign multiple user roles if its nessecary, but we will start with only one). They again inherit rights from the user role but can also have custom overrides.

4. Sevlets

Each servlet has to define a minimumBaseUserRole required to use the servlet. This is mostly to protect admin or user only servlets. Also, each servlet must specify right-templates, which are the default rights depending on the BUR. I'm not yet sure what's the best way to make that easy and clean, will try with different approaches.

Also, the servImpl in each servlet will be able to throw a HTTPException, containing a status code and a massage, which get then responded by AbstractAPIHandler. This is to allow the servlet to throw good error messages based on it's fine grained rights.

---

This should allow us to have a fine grained system for rights, with great configuration options, while also having some basic and hard to confuse protection mechanism in the java code. It will (hopefully) allow authors of servlets to do everything they need within the servlet itself, without having to touch anything else, preventing confusion.

[rmader]

Status update

Todo-list:

• [x] base-user-roles
• [x] user-roles
  • [x] inheritance of base-user-roles
  • [x] loading / storing
  • [x] default user-roles
• [x] each user get's a user-role assigned (which in turn is derived from a base-user-role)
• [x] permissions:
  • [x] permission templates in servlets
  • [x] enheritance
  • [x] overrides
• [ ] administrative tools:
  • [ ] user-management servlet
  • [ ] app to use

Temporary servlets for testing:

• at /api/authorization-demo.json you can currently find an example for the authorization system. The class is at api/cms/AuthorizationDemo.java
  • at /api/change-user-role.json, a logged in user from localhost can change her roles. For example, call '/api/change-user-role.json?userRole=admin' to it to become admin.

working branch: https://github.com/loklak/loklak_server/tree/authorization2