5:33 a.m.
[
https://issues.jboss.org/browse/WFWIP-257?page=com.atlassian.jira.plugin....
]
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@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@2.3.3.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at
org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at
org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at
org.jboss.threads@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@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@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:254)
at
org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
at
org.wildfly.extension.undertow@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@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@1.6.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.AuthenticationManager.lambda$configure$2(AuthenticationManager.java:98)
at
io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:442)
at
io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:121)
at
io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:224)
at
io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186)
at
io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at
io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at
org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at
org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at
org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at
io.undertow.servlet@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)
2446
days inactive
2446
days old
0 comments
1 participants
participants (1)
-
Jean Francois Denise (Jira)