Provide pluggable authorization handlers

[wstrange]

A service may want to restrict methods that a client can invoke. For example, requiring a client to have an OAuth access token with certain scopes.

Shelf middleware could be used in front of the rpc handler - but this means that every method would need to allow the same set of scopes.

A pluggable handler would be useful. Perhaps allowing access to the shelf context in case HTTP headers or body need to be introspected.

This might be extended to a more general purpose mechanism - not just for authorization. Provide pre/post method interception handlers.

Not sure how hard it would be to implement, but annotations like this would be really sweet:

@apimethod(method: 'POST', path: 'resource/{name}/update', scopes: ["http://foo.com/update"])

[wibling]

Hi Warren,

I will look into this. In the case of extending the ApiMethod annotation I expect you would like the scopes to be validated by the framework, right?

Cheers,
/gustav

[wstrange]

Yes - exactly!

[enyo]

This would also be great, since the generated discovery API document should include the scopes necessary for each request.
Is there an ETA for this feature? I am struggling to build an API with dart-lang/rpc that provides proper authentication (I want to use JWT).

[wibling]

Hi Matthias,

Would it be possible for you to use the shelf package in conjunction with the RPC package to achieve this. E.g. something like how the logging is done in the RPC example, https://github.com/dart-lang/rpc-examples/blob/master/bin/shelf_sample.dart.

Basically you setup a shelf pipeline and add the JWT authentication handler as middleware?

/gustav

[wstrange]

That does sort of work - but it is not optimal.

The example above is for authentication. Assuming you want all methods to be protected, it is probably OK to have a blanket shelf filter that protects everything.

But what if you want some methods to be "public" (i.e. not protected). You have to do some kind of URL filtering in shelf -which gets really awkward.

And authorization will almost always be finer grained. EG: "Admins" can call this method, but not normal users. To do that in shelf you are going to need a parallel set of URL filters that mirror your RPC methods. That seems really kludgy.

Being able to filter at the method level on scopes makes this much simpler to implement vs. shelf filters.

I am guessing that people will want general purpose pre and post method interceptors. If you had such a mechanism you could implement authorization scope filters with a plugin.

[enyo]

Thanks for your reply @wibling.

That's how I do it at the moment:

  var apiRouter = shelf_route.router()
    ..add('/api/v1/account', null, apiHandler, exactMatch: false, middleware: loginMiddleware)
    ..add('/api', null, apiHandler, exactMatch: false)
  ;

Although that works it creates a problem: the authorization and validation is done on a path level. So if, for some reason, I move my account routes to another path (eg: /api/v1/user) my loginMiddleware will suddenly become inactive.

It also becomes a bit difficult to add different scopes for different routes, since I suddenly need to maintain the router setup, with the different paths, and make sure that they are in sync with the routes defined in my API.

[wstrange]

Perhaps a new issue should be created?

Define a plugin mechanism for RPC. The plugins should allow for pre and post method handlers, and should give access to the current request context. Perhaps the plugin should be able to access annotations on the method.

Such a plugin could be used to implement things like scope handlers.

[platelk]

I think that this could be a really great features too, it could be a really great mecanisme to implement authentification, check access level etc.

[wibling]

[email protected]

I see your points. I am myself a bit preoccupied with another project at
the moment.

Faisal is this something you are interested in and have time to look at?

/gustav

On Mon, Aug 31, 2015 at 6:52 PM, Vink [email protected] wrote:

I think that this could be a really great features too, it could be a
really great mecanisme to implement authentification, check access level
etc.

—
Reply to this email directly or view it on GitHub
#31 (comment).

[FaisalAbid]

@wibling Yep I'll take this task on. Been wanting this too.

[wibling]

Great!

/gustav

On Wed, Sep 2, 2015 at 3:56 PM, Faisal Abid [email protected]
wrote:

@wibling https://github.com/wibling Yep I'll take this task on. Been
wanting this too.

—
Reply to this email directly or view it on GitHub
#31 (comment).

[FaisalAbid]

Update on this, been super busy with work, but it's coming!

[enyo]

@FaisalAbid any update? :)

[RdeWilde]

Maybe a small POC so others can add to it?

[enyo]

The first great addition would be to allow scopes to be defined on the ApiMethod. There wouldn't need to be any additional handling since then, at least, we could write middleware that does authentication or checking for given scopes.

[artem-malko]

Hello) Any updates? @FaisalAbid