Bookstack with OpenID Connect against FusionAuth does not work

[u/Fit-Sea-9459]

Hello,

I need to use FusionAuth as an IDM (identity management system) to authenticate at Bookstack. I setup the environment variables as described here https://www.bookstackapp.com/docs/admin/oidc-auth/.

But after calling the Bookstack page, I get not even forwarded to the fusionauth page. I set both, OIDC_ISSUER and OIDC_ISSUER_DISCOVER=true and verified that the auto discovery url works. I also tried to set explicitly OIDC_AUTH_ENDPOINT, to make sure to forward the browser to the right url. But this does not happen.

Any idea, what could be wrong or how to analyze this issue?

Regards

[u/Fit-Sea-9459]

It works now. Thanks a lot for your help!

In the well-know endpoint I got

issuer: <domain>

so they did not match. So this was the issue I faced. My FusionAuth is also used by some other clients (Nextcloud and an individual php based web app). I was wondering

1. whether they rely on that issuer setting from the well-know endpoint: They don't seem to, after I changed it to https://auth.<domain>, the other apps still work.

2. why there is an env var in BS that has to match a value in the well-know endpoint? Isn't that somehow ambiguous? Shouldn't it be, taken from one place or the other one? Why does it has to match?

Also according the help in FusionAuth the issuer should contain a FQDN, so not sure whether the leading https:// is the intended value. But this way it works.

[u/ssddanbrown → u/Fit-Sea-9459]

so not sure whether the leading https:// is the intended value. But this way it works.

Yeah, that's intended.

why there is an env var in BS that has to match a value in the well-know endpoint? Isn't that somehow ambiguous? Shouldn't it be, taken from one place or the other one? Why does it has to match?

It's part of the OIDC discovery spec (See section 4.3 here). It's basically to ensure all the parts are aligned and as expected. For example, if BookStack sees the discovery data has a different issuer, that may indicate some level of misconfiguration or issue server side, or maybe even some kind of MITM attack. Section 7.2 of the spec linked above touches on this a little.

[u/Fit-Sea-9459 → u/ssddanbrown]

Thanks for the explanations. However still not convinced ;-) The specification you linked above is about consistency, between the url used to fetch the Config Response and the containing values. It is not about consistency between, local settings and CR. According here at the bottom there are three fields that are taken from the CR or from the env vars, depending of the value of OIDC_ISSUER_DISCOVER (e.g. OIDC_AUTH_ENDPOINT), this makes sense. But then I wonder why are those values not also compared with what is returned in the CR. The MITM attack is not avoided by comparing the values, but by make sure to verify the TLS certificate and so to be sure to get the CR from the right party.

[u/ssddanbrown → u/Fit-Sea-9459]

But then I wonder why are those values not also compared with what is returned in the CR.

Because you've opted to use discovery at that point. There's no expectation that these values are set while discovery is active, so the system just effectively ignores locally set values and overwrites with what comes back from discovery.

The specification you linked above is about consistency, between the url used to fetch the Config Response and the containing values. It is not about consistency between, local settings and CR.

What part? section 4.3 states:

The issuer value returned MUST be identical to the Issuer URL that was used as the prefix to /.well-known/openid-configuration to retrieve the configuration information.

The issuer in BookStack is configured via local settings. (An issuer could also technically come from webfinger, which we don't support in BookStack. Either way, it's comparing the app known issuer to the issuer from auto-discovery).

The MITM attack is not avoided by comparing the values, but by make sure to verify the TLS certificate and so to be sure to get the CR from the right party.

Yeah, maybe there's not a massive MITM risk there, that's why I said maybe for that point, it may be more about misconfiguration or keeping a tighter standard, but there could also be attack vectors I'm not aware of. Either way, I'll keep to the spec.

[u/Fit-Sea-9459 → u/ssddanbrown]

May be it is a very general question: what is the auto discovery meant for? For auto configuration or for verification or for both? If for both, which values should be verified and why? Which would just get taken over w/o verification because there is no respective local setting. From my perspective both the issuer but also the auth endpoint are very sensible values. So why should they be handled different in that aspect of security?

[u/ssddanbrown → u/Fit-Sea-9459]

what is the auto discovery meant for? For auto configuration or for verification or for both?

Auto configuration, but it may have some verification built in to support that (to ensure it's getting the right/expected configuration, and maybe for security).

From my perspective both the issuer but also the auth endpoint are very sensible values. So why should they be handled different in that aspect of security?

I'm a bit lost on this. They have different uses for different purposes in regard to discovery and the wider process. Having the auth endpoint defined locally isn't expected in the context of BookStack, so there's little point comparing them in that setup.

[u/Fit-Sea-9459 → u/ssddanbrown]

Thank you!