SSO patch without Docker - 500 Internal Server Error #8
Comments
|
I have no experience applying SSO-patch a non-Docker Nexus instance, so given the difficulty of diagnosing, I can't make specific recommendations for setting up this configuration. To applying SSO-patch your Nexus instance you need to follow all instructions from https://github.com/a-langer/nexus-sso/blob/main/Dockerfile, including copying scripts and configs to ${NEXUS_HOME}/etc/sso/script/com/github/alanger/nexus/bootstrap/. I can assume that Nexus outside the container determines the current directory differently, therefore it cannot read some configuration files (in all configs, a relative path to the ETC directory is used). The error returned will always be <root level="${root.level:-TRACE}">
...Please give feedback if you manage to find the right settings to apply the SSO-patch outside of Docker. |
|
@a-langer Hello, I enabled full TRACE logging in nexus logback.xml and the 2 most interesting log traces that I could find were these: and I only found a reference here: https://github.com/a-langer/nexus-sso/blob/main/etc/sso/script/com/github/alanger/nexus/bootstrap/EchoRealm.java#L8C31-L8C52 but I can't seem to understand where it is being set. |
|
As I wrote earlier, I have no experience with the SSO patch on Nexus without Docker, so I can't give any advice on setting up this configuration. |
|
Okay @a-langer I think I found the error/issue. I enabled full tracing on our nexus with adding/editing this in our logback.xml Because nexus is outputting/spamming a lot of debug output, it was hard to catch the error at first time. After reading this, I checked the After seeing this, I immediately saw what the problem was. After that we follow the override/copy process like described in the Dockerfile: https://github.com/a-langer/nexus-sso/blob/main/Dockerfile#L16-L30 BUT the issue lies here: https://github.com/a-langer/nexus-sso/blob/main/Dockerfile#L29C16-L29C16 Which is ofcourse not a valid keystore format and which will break the sso patch. So maybe we need to update the README to also mention that git lfs needs to be enabled to clone this file correctly :) |
|
Great job! Thank you for your hard work. I removed JKS storage from LFS, now it is loaded as a binary file c71047a. |
|
@a-langer Hmm, after pulling your updated changes, the Before: After |
|
I changed the storage format to a newer one, try checking through keytool: keytool -list -keystore etc/sso/config/samlKeystore.jks -storepass pac4j-demo-passwdOutput in my case: |
|
@a-langer I checked it with the You will see the error message that the key Or just remove |
|
It turns out that keytooll from JDK 8 not supported new JKS format (previously tested on JDK 11): # openjdk version "1.8.0_332"
keytool -list -keystore etc/sso/config/samlKeystore.jks -storepass pac4j-demo-passwd
keytool error: java.io.IOException: Invalid keystore formatHowever, in the application itself, JKS storage works. |
|
My nexus application is still not working -> Internal server 500 error on Nexus server is running on openjdk 1.8.xxx, just like the container image. |
I also do not understand this logic. When reading the pom.xml file https://github.com/a-langer/nexus-sso/blob/main/pom.xml, the patch is meant to be build with java jdk 8 only. But your |
|
Uploaded compatible JKS format PKCS12 for JDK 8 75d4033 |
|
Yes now it works perfectly on my EC2 instance! Closing issue. |
a-langer
changed the title
a-langer
added
bug
a-langer
changed the title
Hello,
We have a nexus on an EC2 instance on AWS where we applied the SSO patch by:
We see the "Sign in with SSO" button but when we click on it, we end up on the
/index.htmlendpoint with aError 500 Internal Server Errorpage from nexus jetty server.We use the default XML files (
metadata-keycloak.xml metadata.xml samlKeystore.jks shiro.ini sp-metadata.xml urlrewrite.xml) that are already provided in this repo. So we should get a redirect to Okta, like on the demo docker image.We also already added these lines to our
logback.xml: https://github.com/a-langer/nexus-sso/blob/main/docs/SAML.md#debug but with no luck. We do not see more related logging about theerror 500.We also do not use an .env file, but I could not see what env vars are critical to make this work.
At this moment we are looking for a needle in the haystack. Without better logging, we can not find the problem.
The text was updated successfully, but these errors were encountered: