Multi tenancy for Resource Server

[jzheaux]

No description provided.

[jzheaux]

@rwinch I'm using only AuthenticationManager to support multi-tenancy. The reason is because it's possible for Authentication to contain all the necessary information to resolve tenant differences.

Originally, I tried out an AuthenticationManagerResolver.resolve(HttpServletRequest), though I'm of the mind that there's value in this interface not being tied to the request. In my experimentation with alternatives, it was simpler (no new interfaces) to simply allow the user to supply a custom AuthenticationManager and a custom AuthenticationDetailsSource.

This has a nice cognate on the reactive side, injecting a custom ServerAuthenticationConverter to get an Authentication, and then send that Authentication to a custom ReactiveAuthenticationManager.

I'm open to discussion here, of course.

[jgrandja]

Related #5385

[jgrandja]

@jzheaux I don't think it makes sense to use AuthenticationDetailsSource for extracting the tenant info. In this example, AuthenticationManager indirectly relies on HttpServletRequest which is not the intended design for AuthenticationManager as it's not meant to be tied to the web-tier - it should work on a desktop application for example.

Also, the tenant info may come from a request parameter so I'm not sure how this would work with the current setup.

Either way, I feel we need to extract the tenant info in the web-tier and populate it with a new impl of Authentication that is passed into AuthenticationManager. We may even consider a new type that is populated in a AuthenticationDetailsSource? I just think we should leave the extracting of the tenant info in the web-tier - Filter or something similar.

[jzheaux]

In this example, AuthenticationManager indirectly relies on HttpServletRequest

What do you mean that it is indirectly reliant? By that same logic, isn't it also indirectly reliant on HttpServletRequest because of the bearer token resolver? No web-ness makes it down into the authentication manager. We just have a tenantId that so happens to be the path.

This also happens on the reactive side. The AuthenticationWebFilter calls a ServerAuthenticationConverter, which takes a request and returns an Authentication, which is then passed to a manager.

We may even consider a new type that is populated in a `AuthenticationDetailsSource

A stronger type may be in order, as you said, though. Calling setDetails(Object) doesn't offer any type safety, nor any direction on what ought to go there. However, I don't think that I'd want to enforce it at the setter level. For example, I wouldn't want to do this:

public void setAuthenticationDetailsSource
    (AuthenticationDetailsSource<HttpServletRequest, Tenant>)

Since there are certainly other scenarios where the user would like to provide details in the Authentication object.

I just think we should leave the extracting of the tenant info in the web-tier - Filter or something similar.

Just to be clear, this is already technically the case since the filter calls source.buildDetails before invoking the authentication manager. But, I'm thinking you are calling out something more nuanced than that.

[jgrandja]

@jzheaux Regarding my comment

AuthenticationManager indirectly relies on HttpServletRequest which is not the intended design...

Please ignore as I misinterpreted the implementation on my initial look. All seems fine. Actually, I like the fact that you're leveraging Authentication.details to store the tenant info. This allows for an easy integration.

I'm wondering if it makes sense to leverage (or extend) WebAuthenticationDetailsSource and store the tenant info in WebAuthenticationDetails or subclass of it?

[rwinch]

I like how this turned out. It is a simple and yet very powerful change.