Simplify account setup flow by removing redundant WebFinger query

[kaivol]

Simplify the account setup wizard by removing an unnecessary initial WebFinger query that was previously used to discover the IdP server's URL.

This URL is only used on the first login, and not saved when the client is closed. Instead, we rely on the rewrite /.well-known/openid-configuration hack.

[TheOneRing]

I'm sorry, but as mentioned in #271 this is used in a multi tenancy scenario with independent OpenClouds.
With the unauthenticated request, we receive the actual server url.

1. request to my-orga.example -> project1.example
2. request project1.example

[kaivol]

Thanks for the answer!

I'm sorry, but as mentioned in #271 this is used in a multi tenancy scenario with independent OpenClouds.
With the unauthenticated request, we receive the actual server url.

Could you explain what you mean with actual server url?
I'm not familiar with OpenCloud in multi-tenancy setups. This seems to be a new feature, is it documented anywhere?

Also, I don't think the description in #271 is correct.
In particular, as far as I can tell, the authentication server URL is not saved after the initial setup (at least not for subsequent launches of the client), contrary to what is shown in #271 (comment).
Also, I'm not sure if that would be desirable, as it would mean that users would need to do the setup again if the servers changes its auth configuration?

Here is how I understand the currently implemented logic:

1. The DiscoverWebFingerServiceJobFactory gets the OIDC Issuer URL from the OpenCloud WebFinger service, which is typically set via the OC_OIDC_ISSUER environment variable.
2. Via the SetupWizardAccountBuilder this value finds its way to the OAuthCredentialsSetupWizardState constructor, where it is assigned to the authServerUrl variable.
3. This variable is passed to OAuthCredentialsSetupWizardPage and shown in the UI, and it is used to create an instance of OAuth. In the OAuth class, the /.well-known/openid-configuration is fetched based on this URL.
   However, this value is not saved anywhere, and after a restart the OpenCloud server's URL is used for this purpose (utilizing the rewrite /.well-known/openid-configuration hack). So we might just as well get rid of this additional logic.

Where am I missing anything here?

[TheOneRing]

You're right, my explanation and the content of #271 is incorrect and or lacking details.
I contacted the backend team and the documentation of the web finger workflow can be found here.
https://github.com/opencloud-eu/opencloud/tree/main/services/webfinger#webfinger

[kaivol]

Thanks again for the response!

If I'm not mistake, that means that my initial understanding is correct, and the current implementation (in the client) is somewhat nonsensical, isn't it? In particular, the fact that we only use the the OIDC issuer from the WebFinger for the initial account setup.

Wouldn't it make more sense to do the OIDC issuer lookup immediately before retrieving the OIDC metadata (see #776)?

[tbsbdr]

relates to opencloud-eu/opencloud#2072

[kaivol]

Yes, see also my follow-up PR #776.
However, this PR in itself is independent of any such changes proposed in opencloud-eu/opencloud#2072

[TheOneRing]

As mentioned in https://github.com/opencloud-eu/opencloud/tree/main/services/webfinger#webfinger

Webfinger

The webfinger service provides an RFC7033 WebFinger lookup of OpenCloud resources, relevant for a given user account at the /.well-known/webfinger enpoint.

1. An OpenID Connect Discovery for the IdP, based on the OpenCloud URL.
2. An Authenticated Instance Discovery, based on the user account.

These two request are only needed for discovery.

The first web finger request is to discover the IDP. Once authenticated on that IDP we can perform an authenticated web finger request to discover the actual server.

This is only required during the initial setup. Here we rely, historically, on a redirect of https://opencloud/.well-known/openid-configuration to https://idp/.well-known/openid-configuration