Proxy supports authentication / authorization for specific routes

[Tratcher]

When defining proxy routes we should be able to specify Authorization criteria for that route and avoid proxying requests until that criteria is met.

This will need some support to be specified from config (probably by specifying the name of an authz policy that's configured in code), but it should also be configurable when using other data sources.

[Kahbazi]

avoid proxying requests until that criteria is met

This would be done by AuthorizationMiddleware, YARP doesn't need to do anything, right?

This could be the config.

"Routes": [
  {
    "RouteId": "backend1/route1",
    "BackendId": "backend1",
    "Match": {
      "Methods": [ "GET", "POST" ],
      "Host": "localhost",
      "Path": "/{**catchall}"
    },
    "AllowAnonymous": false,
    "Authorize": [
      {
        "Policy": "Policy1",
        "Roles": "Role1,Role2",
        "AuthenticationSchemes": "jwt"
      },
      {
        "Policy": "Policy2",
        "Roles": "Role3",
        "AuthenticationSchemes": "jwt"
      }
    ]
  }
]

and we could create IAuthorizeData, IAllowAnonymous in
https://github.com/microsoft/reverse-proxy/blob/ea7164c689ea06343b99a30aa7feecef4eda215d/src/ReverseProxy.Core/Service/DynamicEndpoints/RuntimeRouteBuilder.cs#L51-L66

My only question is that do we need two identical class for Authorize? One for ProxyRoute and one for ParsedRoute?

[Tratcher]

avoid proxying requests until that criteria is met

This would be done by AuthorizationMiddleware, YARP doesn't need to do anything, right?

Right. MVC does have an extra safety check in it to make sure the AuthorizationMiddleware ran, and we might copy that, but that should be all we need.

I hesitate to actually craft Authorize policies from scratch as part of the proxy config. If we really want to build those in config then that should be an AspNetCore feature outside of the proxy section that we reference by policy name.

[Kahbazi]

I hesitate to actually craft Authorize policies from scratch as part of the proxy config. If we really want to build those in config then that should be an AspNetCore feature outside of the proxy section that we reference by policy name.

I'm on the same page with you. Policy1 and Policy2 that I wrote in config would be a reference to ASP.NET Core policies. Just like the authentication scheme.

Do you think there should be also a config to set authorization for all routes?

[Tratcher]

Do you think there should be also a config to set authorization for all routes?

I don't know. I wonder how often you'd be able to use the same policy for every route? And if you did, that doesn't seem like dynamic data anymore so you'd probably do it in code?

[WeihanLi]

Do you think there should be also a config to set authorization for all routes?

I don't know. I wonder how often you'd be able to use the same policy for every route? And if you did, that doesn't seem like dynamic data anymore so you'd probably do it in code?

maybe compose Backend authorization and Route authorization is better, like controller and action in mvc, use route authorization policy if route policy exists, otherwise use backend authorization policy

[Tratcher]

maybe compose Backend authorization and Route authorization is better, like controller and action in mvc, use route authorization policy if route policy exists, otherwise use backend authorization policy

I don't follow. There wasn't any proposal here to have backend authorization policies, only route auth policies.

[WeihanLi]

maybe compose Backend authorization and Route authorization is better, like controller and action in mvc, use route authorization policy if route policy exists, otherwise use backend authorization policy

I don't follow. There wasn't any proposal here to have backend authorization policies, only route auth policies.

Mostly the same backend(aka the same service) use the same authorize policy in our cases.
For example, routes in the same service need the same scope, if only routes authorize, I had to config every route with the same policy, it's not so convenient for this case.

[jmezach]

I agree with @WeihanLi that it is useful to be able to configure the authorization policy once for a backend (or cluster as it is now called) as most routes going to that backend will need to have the same policy applied.

I'm guessing we might need to have the ability to override it for specific routes though, if that makes sense. For example, we currently have some API's that are available anonymously, while most of them require authentication.

[Tratcher]

@WeihanLi, @jmezach we have #164 tracking ways to reduce redundant config across routes, which should also be useful in this scenario.

I hesitate to enable authorization at multiple layers because then you need to deal with the scenarios where they conflict. People are already confused about how that works in MVC when you define authorization at both the controller and action level.

[WeihanLi]

@WeihanLi, @jmezach we have #164 tracking ways to reduce redundant config across routes, which should also be useful in this scenario.

I hesitate to enable authorization at multiple layers because then you need to deal with the scenarios where they conflict. People are already confused about how that works in MVC when you define authorization at both the controller and action level.

I think there's no confused, just like mvc controller authz and action authz, if there's action authz then action authz takes effect, that's not conflicts but something like priority, action authz priority is higher than the controller authz.

[Tratcher]

You'd be surprised how many issues get filed for the mvc auth scenarios.