Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oidc does not work #24122

Closed
hantsy opened this issue Oct 1, 2022 · 17 comments
Closed

Oidc does not work #24122

hantsy opened this issue Oct 1, 2022 · 17 comments
Labels

Comments

@hantsy
Copy link

hantsy commented Oct 1, 2022

Environment Details

  • GlassFish Version (and build number): Glassfish 7.0.0-M9
  • JDK version: 17
  • OS: Windows 10 Pro
  • Database: not use db in this example

I have created a simple example project to experience Oidc in the latest Glassfish milestones(M8, M9), but it still does not work. When running the project on Glassfish, open a browser and navigate http://localhost:8080/security-oidc-examples/protected, instead of redirecting to Oidc login page, it always prompts a HTTP Basic FORM, see eclipse-ee4j/soteria#325.

But I have tried my example on WildFly 27.0.0.Alph5/Beta1, it worked well with Keycloak, Okta, but there is JwtDecode exception when using Auth0 as Oidc provider, see https://stackoverflow.com/questions/73752379/jakartaee-10-openidauthenticationmechanism-failed-with-auth0.

My Example project is here: https://github.com/hantsy/jakartaee10-sandbox/tree/master/security-oidc

  • Run on Glassfish: mvn clean package cargo:run -Pglassfish
  • Run on WildFly: mvn clean package wildfly:run -Pwildfly
@OndroMih
Copy link
Contributor

OndroMih commented Oct 1, 2022

Hi, the problem isn't in GlassFish but in your configuration.

You placed the annotation @OpenIdAuthenticationMechanismDefinition on the servlet ProtectedServlet. Your project contains an empty beans.xml, which in Jakarta EE means that the bean discovery is "annotated", and there ProtectedServlet isn't a CDI bean. This is a change from Jakarta EE 9 (GlassFish 6), where it meant that the bean discovery was "all".

You can fix this by one of the following solutions:

  • move the @OpenIdAuthenticationMechanismDefinition to another class, which is a CDI bean, for example to com.example.OpenIdConfig
  • set bean discovery in beans.xml to "all"
  • turn the ProtectedServlet into a CDI bean by adding a bean-defining annotation to it, for example @RequestScoped

If your code works in WildFly, it maybe includes servlets in the scanning for @OpenIdAuthenticationMechanismDefinition, or it turns servlets into CDI beans automatically, but none of this is expected. And it's not a bug if GlassFish doesn't turn servlets into CDI beans automatically.

@hantsy
Copy link
Author

hantsy commented Oct 2, 2022

You placed the annotation @OpenIdAuthenticationMechanismDefinition on the servlet ProtectedServlet.

I have checked the tck examples, it also used this approach.

Your project contains an empty beans.xml, which in Jakarta EE means that the bean discovery is "annotated", and there ProtectedServlet isn't a CDI bean.

I do not think so, Servlet (@WebServlet, @WebFilter, etc) , Ejb(@Stateless, @Stateful), Jaxrs (@Path, @Provideretc) annotations should be aware of CDI Context, and they can inject a CDI bean in a Jakarta EE containter, CDI should create proxies for Jakarta EE components and make they work as CDI beans. So I think put @OpenIdAuthenticationMechanismDefinition on a pure Servlet should work.

The annotated only filters out the POJOs(which work as CDI beans by default in the CDI 1.0).

turn the ProtectedServlet into a CDI bean by adding a bean-defining annotation to it, for example @RequestScoped

I will try to move @OpenIdAuthenticationMechanismDefinition to a CDI bean. Thanks.

@hantsy
Copy link
Author

hantsy commented Oct 2, 2022

OK, move the OpenId config to the existing OpenIdConfig bean, and run the application, navigate the /protected and got the following exception.

[2022-10-02T14:04:22.678294+08:00] [GlassFish 7.0] [SEVERE] [] [jakarta.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=66 _ThreadName=http-listener-1(5)] [levelValue: 1000] [[
  Jakarta Authentication: Exception during validateRequest
jakarta.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:270)
	at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:297)
	at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$0(JerseyInvocation.java:662)
	at org.glassfish.jersey.client.JerseyInvocation.call(JerseyInvocation.java:697)
	at org.glassfish.jersey.client.JerseyInvocation.lambda$runInScope$3(JerseyInvocation.java:691)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:205)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:390)
	at org.glassfish.jersey.client.JerseyInvocation.runInScope(JerseyInvocation.java:691)
	at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:661)
	at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:413)
	at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:313)
	at org.glassfish.soteria.mechanisms.openid.controller.ProviderMetadataController.getDocument(ProviderMetadataController.java:83)
	at org.glassfish.soteria.mechanisms.openid.controller.ProviderMetadataController$Proxy$_$$_WeldClientProxy.getDocument(Unknown Source)
	at org.glassfish.soteria.mechanisms.openid.controller.ConfigurationController.buildConfig(ConfigurationController.java:111)
	at org.glassfish.soteria.mechanisms.openid.controller.ConfigurationController.produceConfiguration(ConfigurationController.java:83)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
	at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:103)
	at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:180)
	at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96)
	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:177)
	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:102)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
	at org.glassfish.soteria.mechanisms.openid.domain.OpenIdConfiguration$Proxy$_$$_WeldClientProxy.getProviderMetadata(Unknown Source)
	at org.glassfish.soteria.mechanisms.openid.controller.AuthenticationController.authenticateUser(AuthenticationController.java:94)
	at org.glassfish.soteria.mechanisms.openid.controller.AuthenticationController$Proxy$_$$_WeldClientProxy.authenticateUser(Unknown Source)
	at org.glassfish.soteria.mechanisms.OpenIdAuthenticationMechanism.authenticate(OpenIdAuthenticationMechanism.java:237)
	at org.glassfish.soteria.mechanisms.OpenIdAuthenticationMechanism.validateRequest(OpenIdAuthenticationMechanism.java:176)
	at org.glassfish.soteria.mechanisms.OpenIdAuthenticationMechanism$Proxy$_$$_WeldClientProxy.validateRequest(Unknown Source)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
	at org.jboss.weld.generated.proxies.security.enterprise.authentication.mechanism.http.HttpAuthenticationMechanism$152184814$Proxy$_$$_WeldClientProxy.validateRequest(Unknown Source)
	at org.glassfish.soteria.mechanisms.jaspic.HttpBridgeServerAuthModule.validateRequest(HttpBridgeServerAuthModule.java:89)
	at com.sun.jaspic.config.factory.singlemodule.DefaultServerAuthContext.validateRequest(DefaultServerAuthContext.java:54)
	at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1336)
	at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:480)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:554)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:579)
	at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:555)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:121)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:294)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:187)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:440)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:144)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:174)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:153)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:196)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:88)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:246)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:178)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:118)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:96)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:51)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:510)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:82)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:83)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:101)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:535)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:515)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1357)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1232)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1175)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458)
	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1505)
	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1420)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
	at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:580)
	at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:187)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589)
	at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:529)
	at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308)
	at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:380)
	at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:268)
	... 73 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)
	at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306)
	at java.base/sun.security.validator.Validator.validate(Validator.java:264)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1341)
	... 92 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
	at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
	... 97 more
]]

@krishnakittu
Copy link

krishnakittu commented Oct 2, 2022 via email

@hantsy
Copy link
Author

hantsy commented Oct 2, 2022

The JDK and GlassFish should recognize the certification issued by the public cert authorities. The above exception is thrown when using Auth0 provider.

@krishnakittu
Copy link

krishnakittu commented Oct 2, 2022 via email

@hantsy
Copy link
Author

hantsy commented Oct 3, 2022

Almost all OAuth2/Oidc IDPs have used HTTPS/SSL to protect their URLs, for me, it is impossible to add the private cacerts they are using into my local Glassfish.

@dmatej
Copy link
Contributor

dmatej commented Oct 3, 2022

You can run something like this:

keytool -importkeystore -srckeystore /usr/lib/jvm/jdk17/lib/security/cacerts -destkeystore  /app/appservers/glassfish7/glassfish/domains/domain1/config/cacerts.jks

This is not about private keys, but default cacert.jks contains just two self-signed certificates of GlassFish.

@OndroMih
Copy link
Contributor

You can also try removing the custom trust store in GlassFish. The domain.xml contains this in JVM options:

<jvm-options>-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks</jvm-options>

Stop GlassFish, delete that line, and start GlassFish again. It should use the default truststore in the JDK, which is usually up to date with commonly used certificates like Google's certificate.

@hantsy
Copy link
Author

hantsy commented Nov 26, 2022

Thanks @OndroMih , will try it later.

For my opinion, I hope I can ran the security sample without any modifications.

@OndroMih
Copy link
Contributor

I understand. But this is how GlassFish has always worked - by default, it only accepts certificates certificates in the cacerts file in the domain config directory. And this is global behavior set for the whole JVM, so it impacts anything that works with certificates.

It would make sense to provide an option to disbale validating certificates in he OIDC connector, or an option to check certificates also against the default JDK trust store. But it's not a bug per se, because the current behavior is intended for security reasons. You wouldn't want to blindly accept a remote certificate and expose yourself to an attack. It makes sense for demos, but not for real world deployments.

@hantsy
Copy link
Author

hantsy commented Dec 6, 2022

@OndroMih Got it, thanks.

But this stop me to use it in testing codes or in Github actions to verify the functionality automatically.

@OndroMih
Copy link
Contributor

OndroMih commented Dec 6, 2022

What you can do is remove the -Djavax.net.ssl.trustStore JVM option in GlassFish's domain.xml, then GlassFish will use the trust store from the JDK. If you have a recent JDK, it should contain certificates for widely used services like Google.

In the future, we'll look how to provide an option to disable validating certificates in the OIDC connector for demo purposes.

@dmatej
Copy link
Contributor

dmatej commented Dec 7, 2022

Maybe we could add an asadmin command to import all certificates from another repository.
Basically the opposite direction doesn't make sense, because

  • GF needs to have write permissions to it's keystores to write the self-signed certificate
  • For production environment it is useful to have rather quite strict control over trusted certificates. Especially when server instances don't have direct access to the internet to check CRL etc.
  • That's another issue - cluster instances should use the same controlled keystore (or a set of keystores based on config) despite each instance would run on own computer and operating system (maybe even with different OS and architecture, years back we had Solaris+Sparc and RedHat+Intel+virt in a single cluster and it worked well even to my surprise).

The asadmin command would do the same as keytool, but it would use "target" (config name/instance name/domain name) instead of dest keystore file path.

@magical-heyrovsky
Copy link

magical-heyrovsky commented Oct 2, 2023

Has anyone ever managed to make Glassfish work with Keycloak and maybe even has an example? What providerURI does @OpenIdAuthenticationMechanismDefinition expect? Should it look like this?: https://my-keycloak.com/auth/realms/my-realm/.well-known/openid-configuration

I am always getting

Jakarta Authentication: Exception during validateRequest                                                                                                                
jakarta.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to f
ind valid certification path to requested target

@hantsy
Copy link
Author

hantsy commented Oct 3, 2023

@magical-heyrovsky try this #24122 (comment) or this comment #24122 (comment)

Copy link

github-actions bot commented Oct 3, 2024

This issue has been marked as inactive and old and will be closed in 7 days if there is no further activity. If you want the issue to remain open please add a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants