Support multi-tenancy (dynamic configuration selection)

[sberyozkin]

@teddyjtorres and @ayoho have had an interesting idea about supporting more than one issuer for a single MP JWT endpoint.
During the 2 latest MP JWT calls/notes it was agreed that rather than overloading each MP JWT configuration property (ex, mp.jwt.issuer=iss1, iss2 where each of these issuers may have its own token security requirements) it would be better to follow a multi-tenancy principle or simply, select the MP JWT configuration sets atomically, depending on the properties of the current token.

Option1

Teddy and Adam liked the idea of starting with the static tenant-specific configuration, for example:

my-tenant.mp.jwt.public.key.location=/my-tenant.pem
#etc
// fallback, if  'my-tenant' is not available:
mp.jwt.public.key.location=/publicKey.pem

where my-tenant is the value of either JWS or JWE tenantId header.

Option2

Introduce an injectable interface which would return the current set of properties - it will accept a map of the token headers and return the matching set. Fallback works the same way as in Option1.

CC @radcortez @rdebusscher

[sberyozkin]

I've removed the milestone at the moment until we agree on some final option.

In both (and likely other) cases the extra complexity is that the implementation would have to manually parse the headers first and then once the configuration is chosen - get the underlying JOSE library to parse it (and the whole token again).
The other concern is that we can't expect many providers to set a tenantId header.

In our experience the tenant selection is often driven by the HTTP request properties as opposed to the token content.

[rdebusscher]

I would go for option2 as you also indicate that providers need to set a tenantId. This option2 is more generic and an implementation of the 'interface' can still look at the header tokens to retrieve the value of tenantId.

As you also mention, besides the token, the (HTTP) Request as a whole should also be passed to that method.

[sberyozkin]

@rdebusscher thanks for the comments.

As you also mention, besides the token, the (HTTP) Request as a whole should also be passed to that method.

Right - that can be problematic as it can be hard to come up with a portable representation of HTTP properties which work for all the containers :-). I suppose it can be implicit - the interface implementations can inject HttpServletRequest or other implementation specific HTTP request instance representations - I guess it can work...

[rdebusscher]

Alternative for multi-tenancy support (too make things easier instead of having to setup every 'source' separately)

• key mp.jwt.verify.publickey.location supports a list of locations
• key mp.jwt.verify.publickey.algorithm supports a list of Signatures algorithms.
• Key mp.jwt.decrypt.key.location supports a list of locations
• Key mp.jwt.decrypt.key.algorithm supports a list of encryption algorithms.
• Key mp.jwt.verify.issuer support a list
• Application can accept besides JWS also JWE tokens at the same time (when properly configured through mp.jwt.decrypt.key.location)
• Header and Cookie are not exclusive. When cookie with appropriate is found, the Cookie value is used as JWT token, otherwise the Authorization Header is inspected. (when mp.jwt.token.header is empty = default. When a value specified, only that source is considered)