mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 16:49:47 +03:00
Nextcloud as Identity Provider via the OIDC app, possible redirect problem? #5014
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MarioOsswald on GitHub (Oct 19, 2024).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
I tried yesterday the available NextCloud OIDC App from https://github.com/H2CK/oidc
The Purpose of this app is to use NC as the identity provider. I came close to get this working, but could not solve an issue with the Issuer definition, in particular, I guess, it's a rewrite problem or something related to it.
The details are:
I specified in BS .env file
OIDC_ISSUER=https://mynextclouddomain.tld
When I try a browser request with "https://mynextclouddomain.tld/.well-known/openid-configuration", the NC nginx redirects correctly to "https://mynextclouddomain.tld/index.php/.well-known/openid-configuration" and displays all the desired details, among them at first line 'issuer: "https://mynextclouddomain.tld/"'.
The problem is that BS doesn't get the results from the redirected URL. Instead, I receive an error
"OIDC Discovery Error: Error discovering provider settings from issuer at URL https://mynextclouddomain.tld/.well-known/openid-configuration". The request from BS is not redirected the way the browser request was.
My approach was to change the .env variable to
OIDC_ISSUER=https://mynextclouddomain.tld/index.php
This solves the discovery problem, but then leads to an error message like
"OIDC Discovery Error: Unexpected issuer value found on discovery response". There is then an obvious mismatch, since on BS's side the issuer variable includes the index.php (OIDC_ISSUER=https://mynextclouddomain.tld/index.php), while the discovery response delivers only 'issuer: "https://mynextclouddomain.tld/"'.
A "curl https://mynextclouddomain.tld/.well-known/openid-configuration" delivers (with <>)
html
head title 301 Moved Permanently /title /head
body
center h1 301 Moved Permanently /h1 /center
hr center nginx /center
/body
/html
while a "curl -L https://mynextclouddomain.tld/.well-known/openid-configuration" or "curl https://mynextclouddomain.tld/index.php/.well-known/openid-configuration" delivers the desired results.
I'm not experienced enough with NC or nginx redirect / rewrite features. Since the browser redirects correctly (without any required change from my side), I thought that's enough. I tried a few configurations, with no success. But probably someone more experienced has an immediate idea what to do, so that BS receives the auto discovery results from the correct redirected URL.
Exact BookStack Version
24.10
Log Content
No response
Hosting Environment
PHP8.3 on Ubuntu 24.04 LTS on VPS, official BS installation script used
@ssddanbrown commented on GitHub (Oct 19, 2024):
Hi @MarioOsswald,
For OIDC we stick pretty strongly to the spec, which does not mention allowing redirects for autodiscovery.
You could either somehow look to prevent the redirect to include
index.php(Which seems odd to me for a well-configured mature app like NextCloud but I'm not familiar with the app at all) or potentially you could work around this via some level of proxy at the webserver level (to handlehttps://mynextclouddomain.tld/.well-known/openid-configurationand provide a response forhttps://mynextclouddomain.tld/index.php/.well-known/openid-configuration).@MarioOsswald commented on GitHub (Oct 19, 2024):
Hi @ssddanbrown,
thanks for your fast reply (on a Saturday...), much appreciated!
I don't know where the redirect to include index.php comes from or how to prevent that, but I'll go through the nginx.conf again. To have a special proxy configuratoin for just this purpose would not be my first choice in our otherwise stable running system. But I'll have a look at it.
Could it be an option on your side to introduce two related variables in .env instead of one, for example:
OIDC_DISCOVERY_URL=https://mynextclouddomain.tld/index.php
OIDC_ISSUER=https://mynextclouddomain.tld/
This would, as far as I can say, solve the problem immediately. The discovery would work and the issuer would have no conflict...
@ssddanbrown commented on GitHub (Oct 19, 2024):
I wouldn't be keen to add/maintain extra options on our side to essentially work around environment-specific issues that go against the spec. I'd rather keep strongly to the spec, otherwise the scope of what we support gets stretched to all kinds of scenarios/use-cases.
@MarioOsswald commented on GitHub (Oct 19, 2024):
Very understandable, but it would probably open up a useful integration, since NextCloud became very popular and BS functionality / wiki is not included...
I'm not very familiar with the NextCloud security design, but it appears to be intentional to handle external services this way.
location ^~ /.well-known {
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
location /.well-known/pki-validation { try_files $uri $uri/ =404; }
return 301 /index.php$request_uri;
}
I don't get the oidc auto discovery results without the inclusion of index.php. I'll have a look at the nginx proxy features, maybe it is not the overkill as I expect. I also have the issue posted in the NextCloud oidc app git forum, maybe they have an idea over there...
@MarioOsswald commented on GitHub (Oct 21, 2024):
The NC OIDC app developer advised that Nextcloud it is not able to provide this endpoint without a configured redirect in the NC web server. But he suggested to set OIDC_ISSUER_DISCOVER=false and then to enter the correct details manually.
I did, but I fail to provide the key file (OIDC_PUBLIC_KEY=file:///keys/idp-public-key.pem) in the correct way.
I copied the key from my NC provider (plain text there) and created a folder "keys" on my BS server under /var/www/bookstack, created a file named idp-public-key.pem in that folder and pasted the content of my NC public idp key.
Nevertheless, when trying in BS, it displays the following error:
"ID token validation failed with error: Failed to read signing key with error: Failed to load key from file path with error: file_get_contents(file:///keys/idp-public-key.pem): Failed to open stream: No such file or directory".
Unfortunately, I don't know where exactly BS searches for the file...
@ssddanbrown commented on GitHub (Oct 21, 2024):
Probably easiest to keep it as an absolute path, so:
@MarioOsswald commented on GitHub (Oct 21, 2024):
Problem solved, have NC working as ID provider for BS.
Thanks a lot for your amazing support!
@ssddanbrown commented on GitHub (Oct 21, 2024):
Glad to hear things are now working! Will therefore close this off.