Inversifyjs: Add support for @authorize in inversify-express-utils

[remojansen]

Expected Behavior

We need a declarative authorization API

Current Behavior

Nothing suported out of the box

Possible Solution

Add support for something like @Authorize() @Authorize({ Users: ["Alice"] }) @Authorize({ Roles: ["Admin"] }) so people can do:

@Controller('/foo')
@injectable()
export class FooController implements Controller {

    constructor( @inject('FooService') private fooService: FooService ) {}

    @Get('/')
    @Authorize({ Roles: ["Admin"] })
    private index(req: express.Request): string {
        return this.fooService.get(req.query.id);
    }
}

We probably need to allow users to configure the auth:

let server = new InversifyExpressServer(kernel, authProvider);

The implementations of authProvider could be develop as plugins available on npm.

This was requested by @jhuntoo in Gitter.

Any thoughts @codyjs?

[codyjs]

I like the example, simple and clean.

Some thoughts: This would mean that only one authProvider could be used throughout the entire app, but I think that more granular functionality could be achieved with custom authProviders if needed.

By default, how would the authProvider have access to the User object? Would this be serialized into the session after authentication? (This could be done with Passport)

[lholznagel]

Don´t know why, but I never got warm with Passport.
For accessing the user Object I generate a jwt token and put it into the header field. In the Token I serialized a expire date and the id of the user. So when I need the id I deserialized the token and searched for the id in the database. I think it is possible to insert some parts of the user Object so that we don´t need a database.

[jhuntoo]

I think we could follow asp.net core on this.

In summary we could implement a single @ Authorize decorator that handles, Basic, RBAC, Policy and Claims Based via cookie or token.

Also the @Anonymous looks handy so that u can makes controllers secure by default, and "opt-in" to unsecure routes.

Beyond that, users could create their own Authorization middleware, something similar to this

export class MyAuth implements AuthorizationMiddleware {
  handle(context: AuthorizationContext): AuthorizationResult {
    return (context.identity === 'GOD')
      ? allow()
      : deny();
  }
}

// ***** Supporting Types

export interface AuthorizationContext {
   identity: string;
   request: any;
}

export interface AuthorizationMiddleware {
  handle(context: AuthorizationContext);
}

export interface AuthorizationResult {}

export function deny(options?: any): AuthorizationResult {return {}; }
export function allow(options?: any): AuthorizationResult {return {}; }

[remojansen]

Closing this as well it can be followed at https://github.com/CitadelJS/core/issues/

[centigrade-thomas-becker]

What is the status of this feature? I found a similiar issue #487 that is not resolved either.

[remojansen]

I don't think we can provide authorize as a framework element but you can implement your own, here is an example https://github.com/stelltec/public-tech-demos/blob/master/nodejs-madrid-meetup/demo3/src/ui/rest_api/controllers/secure_controller.ts#L8

[viktor-flower]

I don't think we can provide authorize as a framework element but you can implement your own, here is an example https://github.com/stelltec/public-tech-demos/blob/master/nodejs-madrid-meetup/demo3/src/ui/rest_api/controllers/secure_controller.ts#L8

Is it still the best solution to create a handler processing? I would like a decorator approach like @IsAuthenticated