Authorization

[bryce-anderson]

It would be nice to support authorizations directly in rho. I'm not sure of HAL would benefit from it, but swagger would.
Prior Art:

• Scalatra (suggested to be not so good by @casualjim)
• By proxy, Warden

[arouel]

JSON HAL does not describe the authorization of resources only their references between. But I think its a good to have it.

[zarthross]

@bryce-anderson Authorization has come up again in #158, and I too need some support for it. I would love to help out but could use some guidance as to how it should be implemented.

Some random thoughts/note here:

• It would appear that HAL doesn't do anything with Authentication/Authorization so no need to worry about it.
• The swagger 'security' models appear to be implemented in rho/swagger/src/main/scala/org/http4s/rho/swagger/models.scala but swagger middleware doesn't extract any auth info.
• Swagger supports 3 kinds of authentication: OAuth, Api Key, Basic Authentication
• Swagger supports 1 kind of authorization: Scopes

So where to start?

1. Forget swagger for now and add support for HTTP4s Auth middleware as a stop gap until we can get proper authorization?
2. Create an AuthedRhoService that uses an AuthedRequest instead of a Request object? The AuthedRhoService could specify the security definitions for the service and each request could have a auth and/or 'scopes' extractor on the Route to specify the required scopes or validate the api-key for that route?
3. Just add an extractor like 'Headers' and PathVars work now, but adds the authentication metadata for swagger and a parameter to the Action that contains the User/API_key what have you.

Thoughts?

[zarthross]

I'm somewhat partial to the 3rd one, since you could mix Authed and Unauthed routes in one service. Unfortunately it wouldn't share much with how HTTP4s does authentication since we have to keep the metadata.

[bryce-anderson]

In my minds eye, it would be super useful to allow whole services to be protected at once, but I also don't think this should be mandatory and am not sure how that information would be surfaced to the action.

For the route by route case, I imagine it reasonably easy to be able to make a construct to the tune of

val authenticate: RoutingEntity[T] => RoutingEntity[Auth::T] = ???

val authedRoute = authenticate ( GET / "thesecrets") |>> { auth: Auth => ??? }

which I think is essentially your 3rd strategy and a new class of AuthRules. What type of interface did you have in mind?

A very vague and potentially confusing/spooky idea is to expand the HListToFunction and Action types to be authentication/authorization aware. Another downside is this plan that makes security action based but its often safer to think of it as routing based since even knowing the presence of a resource can be considered a security leak.

[zarthross]

I imagined something not too far off from what your suggesting, might just need to experiment with a couple solutions.

As for the change to HListToFunction, I think it would be enough if the 'authenticate' method added a parameter the function takes instead of changing HListToFunction to be auth aware. I personally think the authentication should be route based, mostly so we can get some data into swagger.

[eklavya]

Looks like a big change with alternative methods for AuthedRequest all the way. Any workarounds for this? I need to mix AuthedService and RhoService. :(