Support resolving issuer from current request

[jacko9et]

The current issuer needs to be set in the configuration, can it be changed to dynamic? Or change ProviderSettings to be extensible.
Refer：ControllerLinkBuilder

[jgrandja]

@lu-cheng Can you provide more detail on why the issuer needs to be resolved at runtime? Typically, the issuer is a host/domain name and is known at configuration/deployment time. Are you resolving using IP address? Is this for non-production environment?

[jacko9et]

@jgrandja Yes, part of the reason is due to environmental issues. If the IP address is fixed, it can be solved by passing parameters at runtime, but when the IP changes frequently and there is no fixed domain name, it is difficult to deal with. The other case is multi-tenancy (saas product), each tenant uses a different subdomain, and the auth-server uses the same set of service instances. At this time, a dynamic issuer is needed.

[jgrandja]

Thanks for the details @lu-cheng.
Let me think about this and I'll get back to you shortly.

[jvalkeal]

It would be nice if uri could be resolved from request as my attempt to run server on k8s and them attempted to point my boot app(running locally) to it. I did modify my /etc/hosts to point issue to localhost so that I can access minikube nodeport but boot app blows up with:

Failed to instantiate [org.springframework.security.oauth2.client.registration.InMemoryClientRegistrationRepository]:
  Factory method 'clientRegistrationRepository' threw exception; nested exception is java.lang.IllegalStateException:
  The Issuer "http://sso.sso" provided in the configuration metadata did not match the requested issuer "http://sso.sso:32530"

When I had setting:

SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_SSO_ISSUER_URI=http://sso.sso:32530

i.e. keycloak changes things in .well-known/openid-configuration based on request which makes it relatively easy to setup with different networks.

[jgrandja]

Thanks for the additional details @jvalkeal. I'll resolve this soon.

[markhobson]

Another use case, related to #258, is being able to set the issuer to local.server.port when running integration tests against the authorization server. The ProviderSettings must be configured on application startup, but the random port isn't known until after startup.

[jgrandja]

@lu-cheng @jvalkeal @markhobson This is now resolved via 666d569.

Can you please confirm the enhancement resolves your specific issue? Thanks!

[markhobson]

Hi @jgrandja, thanks for the change! I've tried my authorization server integration tests against 0.2.1-SNAPSHOT and they work fine when omitting the explicit issuer configuration and infer the random port.

A couple of 0.2.1 related issues I encountered on upgrading, in case it helps others here:

1. Deprecate PasswordEncoder in JdbcRegisteredClientRepository #496 requires client secrets to be encoded externally
2. Deny consent flow breaks when additional request parameters are present

[jgrandja]

@lu-cheng @jvalkeal @markhobson I've been mulling over the solution provided via 666d569 as I'm not quite happy with it. So I decided to revert the change before the release this week.

Unfortunately, it won't make it into 0.2.1 but I do plan on merging the improvements next week.

[jgrandja]

@lu-cheng @jvalkeal @markhobson This is now resolved via d302444

[markhobson]

Works for me, thanks @jgrandja!