[jboss-jira] [JBoss JIRA] (WFWIP-257) SSO layer cannot be properly used with SSO template

[Jean Francois Denise (Jira)]

    [ https://issues.jboss.org/browse/WFWIP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812988#comment-13812988 ] 

Jean Francois Denise commented on WFWIP-257:
--------------------------------------------

Elytron doesn't behave the same way as with legacy security domain. When "other" is set, a check is done for the KEYCLOAK mecchanisms. So it fails when provisioning galleon layers (base layer set the "other" security domain). This is very specific to the "other" security domain. If a "keycloak" application-security-domain is set, then, even if the war doesn't specify a security domain, keycloak will be enabled (thanks to the subsystem).

We have 4 ways (at least as I see it):

1) Document that, when using Galleon base layers in combination with sso layer, one need to specify a security domain in his deployment. This would break the sso test for galleon. This seems acceptable.

2) Remove the existing "other" application-security-domain and replace it with one that understand keycloak, other mechanisms (BASIC, FORM) would be lost. Is it acceptable to to disable other security mechanisms when keycloak is enable? This is not compliant with legacy behavior for which all mechanisms are available once keycloak is enabled.

3) We could remove "other" and only add the "keycloak: security domain. Security other than keyCloak is disabled. Not what we want.

4) We can detect that "other" is set and references the security--domain "ApplicationDomain". Only in this case (because we know how to reconstruct it with common mechanisms BASIC, FORM) we would remove "other", create new elytron SecurityDomain with keycloak and ApplicationDomain realms, create a new http-authentication-factory that aggregates FORM,BASIC with KEYCLOAK mechanisms (OIDC and SAML) and add "other" referencing the http-authentication-factory.

My preference is 4). I discussed with [~fjuma] and this seems doable. I am currently investigating it. [~mjurc], [~brian.stansberry], [~jmesnil] any input?



> SSO  layer cannot be properly used with SSO template
> ----------------------------------------------------
>
>                 Key: WFWIP-257
>                 URL: https://issues.jboss.org/browse/WFWIP-257
>             Project: WildFly WIP
>          Issue Type: Bug
>          Components: OpenShift
>            Reporter: Michal Jurc
>            Assignee: Jean Francois Denise
>            Priority: Blocker
>
> Currently available OpenShift templates for EAP CD are not able to properly configure EAP server with SSO client, resulting in the following errors: 
> {code}15:55:01,843 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 38) MSC000001: Failed to start service jboss.deployment.unit."app-profile-jsp.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."app-profile-jsp.war".undertow-deployment: java.lang.RuntimeException: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow at 7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> 	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 	at org.jboss.threads at 2.3.3.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> 	at org.jboss.threads at 2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> 	at org.jboss.threads at 2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> 	at org.jboss.threads at 2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> 	at java.base/java.lang.Thread.run(Thread.java:834)
> 	at org.jboss.threads at 2.3.3.Final-redhat-00001//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory.
> 	at io.undertow.servlet at 2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:254)
> 	at org.wildfly.extension.undertow at 7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
> 	at org.wildfly.extension.undertow at 7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> 	... 8 more
> Caused by: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory.
> 	at org.wildfly.security.elytron-web.undertow-server-servlet at 1.6.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.AuthenticationManager.initialSecurityHandler(AuthenticationManager.java:153)
> 	at org.wildfly.security.elytron-web.undertow-server-servlet at 1.6.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.AuthenticationManager.lambda$configure$2(AuthenticationManager.java:98)
> 	at io.undertow.servlet at 2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:442)
> 	at io.undertow.servlet at 2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:121)
> 	at io.undertow.servlet at 2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:224)
> 	at io.undertow.servlet at 2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186)
> 	at io.undertow.servlet at 2.0.26.SP3-redhat-00001//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> 	at io.undertow.servlet at 2.0.26.SP3-redhat-00001//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow at 7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> 	at org.wildfly.extension.undertow at 7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> 	at org.wildfly.extension.undertow at 7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> 	at org.wildfly.extension.undertow at 7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> 	at io.undertow.servlet at 2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
> 	... 10 more{code}
> I am marking this issue as blocker since the template is currently the only documented way for EAP to use SSO client on OpenShift.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)