Improve authorization

[MohamedBeydoun]

Currently, most of our authorization is done through the wisp-gateway. This isn't good since nginx logic is limited and offers little versitility for route-specific auth. To improve on our current auth system, we can add a new file called, for example, auth.json that contains a list of routes associated with our services as well as the scopes that are authorized to use them:

{
    "/users": {
        "get": {
            "scope": "USER",
            "userProtected": false
        }
    }
}

note: scope can be USER, ADMIN, INTERNAL, or PUBLIC

Our /auth/introspect would use this file along with request information sent from the gateway to more accurately introspect tokens for proper permissions. The gateway currently sends a token from which the scope can be taken (denoted as role) so we would need to add the query params route (the route being called) and method (http method) to our http.js file in wisp-gateway.

For user protected routes, we flag the routes as such so that we know to compare the token's userId to the userId mentioned in the request uri.

this is a draft spec so feel free to improve on it by commenting on this issue.

[ValerianClerc]

LGTM, I'm not super experienced with auth in general so I can't think of a better alternative.

Is there a way to set a default? Like default set all routes to INTERNAL, and then override route's permissions depending on their purpose. Kind of like firewall rules. This would avoid us forgetting to update the auth.json when we add a new route, and avoid the unwanted/undefined/public access as a result.

[MohamedBeydoun]

LGTM, I'm not super experienced with auth in general so I can't think of a better alternative.

Is there a way to set a default? Like default set all routes to INTERNAL, and then override route's permissions depending on their purpose. Kind of like firewall rules. This would avoid us forgetting to update the auth.json when we add a new route, and avoid the unwanted/undefined/public access as a result.

@ValerianClerc yeah we can make iit so that if the route isn't explicitly mentioned in the json, then it's internal.

[idodin]

Sorry - not super clear on what the auth flow would be like e.g. when accessing some kind of user-protected resource (e.g. updating profile)?

[MohamedBeydoun]

Sorry - not super clear on what the auth flow would be like e.g. when accessing some kind of user-protected resource (e.g. updating profile)?

@idodin Fixed issue description to include user-protected routes (wasn't taking them into consideration before)