Payara SSO with OIDC and Custom Form Authentication

[Jeremy]

Is it possible to utilize the Payara HTTP Service SSO option with two applications on the same domain - one utilizing OIDC and the other utilizing Custom Form Authentication?  

I can successfully authenticate with the OIDC application, navigate to the Custom Form application, and maintain my credentials (via HttpServletRequest - getRemoteUser(), getUserPrincipal(), isUserInRole(), etc.) across the applications.  However, I am encountering a NullPointerException (see below) the other way around - authenticate with the Custom Form application and then navigate to the OIDC application - the NPE occurs within the validateRequest method in the Open Id Authentication Mechanism when attempting to access the OIDC application.  I am attempting to figure out if this is a bug, or perhaps I am attempting to accomplish something that should not be done.  I do realize that OIDC is a SSO option within itself, but I am vetoing accounts that are not within our database.  I would think that once the Custom Form Authentication occurs and populates the HttpServletRequest, SecurityContext, etc. methods that I would be able to navigate freely as an authenticated user between the two applications.

Jakarta EE 8

Payara 5.2021.1

JASPIC: http msg authentication fail

java.lang.NullPointerException

at fish.payara.security.openid.OpenIdAuthenticationMechanism.validateRequest(OpenIdAuthenticationMechanism.java:226)

at jdk.internal.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)

at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.base/java.lang.reflect.Method.invoke(Method.java:566)

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.weldx.security.enterprise.authentication.mechanism.http.HttpAuthenticationMechanism$37414984$Proxy$_$$_WeldClientProxy.validateRequest(Unknown Source)

at org.glassfish.soteria.mechanisms.jaspic.HttpBridgeServerAuthModule.validateRequest(HttpBridgeServerAuthModule.java:151)

at org.glassfish.soteria.mechanisms.jaspic.DefaultServerAuthContext.validateRequest(DefaultServerAuthContext.java:76)

at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:391)

at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:358)

at com.sun.web.security.realmadapter.JaspicRealm.validateRequest(JaspicRealm.java:181)

at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:487)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:726)

at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:581)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)

at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:757)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:577)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:368)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)

at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:520)

at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:217)

at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:182)

at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:156)

at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:218)

at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:95)

at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:260)

at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:177)

at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:109)

at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:88)

at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:53)

at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:524)

at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:89)

at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:94)

at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:33)

at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:114)

at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)

at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)

at java.base/java.lang.Thread.run(Thread.java:834)

[Ondro Mihályi]

Hi Jeremy,

The OpenID authentication mechanism isn't built with SSO support in mind. it always relies on some data provided by the OpenID authentication and will throw exceptions if the data isn't there. SSO works in general and according to your stacktrace, the OpenID mechanism detects that the user is logged in, but it gives an exception because the required data isn't set because the user wasn't logged in by the OpenID mechanism before.

I think it's possible to enhance the OpenID mechanism to work in the SSO setup but currently it doesn't support it.

All the best,

Ondro

po 16. 8. 2021 o 20:35 Jeremy <hin...@gmail.com> napísal(a):

--
You received this message because you are subscribed to the Google Groups "Payara Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to payara-forum...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/payara-forum/e948f837-ce8b-44f0-a30a-408b76e4318cn%40googlegroups.com.

[Jeremy]

Thanks Ondro for the quick response!  This is good to know.

 - Jeremy

[Rudy De Busscher]

Hi Jeremy,

You can use Openid Connect Authentication in both applications and SSO is handled in this case by the OpenId Connect provider. For more information, have a look at https://blog.payara.fish/how-to-use-openidconnect-with-payara-platform-to-achieve-single-sign-on.

The Payara SSO option itself is intended to be used with users stored in a file or database.

Regards

Rudy