[JBoss JIRA] (WFCORE-2162) Authentication against HTTP management interface with empty username causes Internal Server Error (status 500)
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2162?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved WFLY-7666 to WFCORE-2162:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2162 (was: WFLY-7666)
Component/s: Security
(was: Security)
Affects Version/s: (was: 11.0.0.Alpha1)
> Authentication against HTTP management interface with empty username causes Internal Server Error (status 500)
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2162
> URL: https://issues.jboss.org/browse/WFCORE-2162
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha18
>
>
> In case when empty username is passed during authentication to Management Console then exception is thrown to server log and Internal Server Error (status 500) is returned to user (which leads to displaying "Connect to Management Interface" page. User is not able to try to login again.
> In WildFly 10.1.0 this scenario works fine - after passing empty username during authentication, authentication failed and login window is displayed again. I request blocker due to regression.
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (management task-3) UT005071: Undertow request failed HttpServerExchange{ GET /management request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate], User-Agent=[Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0], Connection=[keep-alive], Authorization=[Digest username="", realm="ManagementRealm", nonce="AAAAAwAAAlzTPVPLC0qPi6CaEhTCHZa+QjsuAjn3OsQXcuDYAxrOtc+rRMs=", uri="/management", algorithm=MD5, response="cbd764e6c09577625476340f7bcfc84d", opaque="00000000000000000000000000000000"], Content-Type=[text/plain; charset=utf-8], Cookie=[__utma=111872281.1874867570.1477040206.1479886566.1479982414.11; __utmz=111872281.1477040206.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=111872281.5.10.1479982414; __utmt=1; __utmc=111872281], Referer=[http://localhost:9990/console/App.html], Host=[localhost:9990]} response {X-Frame-Options=[SAMEORIGIN]}}: java.lang.IllegalArgumentException
> at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.getH_A1(DigestAuthenticationMechanism.java:233)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.validateResponse(DigestAuthenticationMechanism.java:189)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.evaluateRequest(DigestAuthenticationMechanism.java:121)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2162) Authentication against HTTP management interface with empty username causes Internal Server Error (status 500)
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2162?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2162:
-------------------------------------
Fix Version/s: 3.0.0.Alpha18
> Authentication against HTTP management interface with empty username causes Internal Server Error (status 500)
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2162
> URL: https://issues.jboss.org/browse/WFCORE-2162
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha18
>
>
> In case when empty username is passed during authentication to Management Console then exception is thrown to server log and Internal Server Error (status 500) is returned to user (which leads to displaying "Connect to Management Interface" page. User is not able to try to login again.
> In WildFly 10.1.0 this scenario works fine - after passing empty username during authentication, authentication failed and login window is displayed again. I request blocker due to regression.
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (management task-3) UT005071: Undertow request failed HttpServerExchange{ GET /management request {Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate], User-Agent=[Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0], Connection=[keep-alive], Authorization=[Digest username="", realm="ManagementRealm", nonce="AAAAAwAAAlzTPVPLC0qPi6CaEhTCHZa+QjsuAjn3OsQXcuDYAxrOtc+rRMs=", uri="/management", algorithm=MD5, response="cbd764e6c09577625476340f7bcfc84d", opaque="00000000000000000000000000000000"], Content-Type=[text/plain; charset=utf-8], Cookie=[__utma=111872281.1874867570.1477040206.1479886566.1479982414.11; __utmz=111872281.1477040206.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=111872281.5.10.1479982414; __utmt=1; __utmc=111872281], Referer=[http://localhost:9990/console/App.html], Host=[localhost:9990]} response {X-Frame-Options=[SAMEORIGIN]}}: java.lang.IllegalArgumentException
> at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.getH_A1(DigestAuthenticationMechanism.java:233)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.validateResponse(DigestAuthenticationMechanism.java:189)
> at org.wildfly.security.http.impl.DigestAuthenticationMechanism.evaluateRequest(DigestAuthenticationMechanism.java:121)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7670) It is possible to create constant-name-rewriter without defined constant
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7670?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7670:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> It is possible to create constant-name-rewriter without defined constant
> ------------------------------------------------------------------------
>
> Key: WFLY-7670
> URL: https://issues.jboss.org/browse/WFLY-7670
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Tymel
> Assignee: Darran Lofthouse
> Labels: user_experience
> Fix For: 11.0.0.Alpha1
>
>
> If user adds a new {{constant-name-rewriter}} via following command {{/subsystem=elytron/constant-name-rewriter=name-rewriter:add(constant)}} then is a new rewriter created.
> It shouldn't be possible since {{constant}} attribute isn't filled correctly. However, there is added a new rewriter with {{true}} value [1] instead.
> [1] <constant-name-rewriter name="name-rewriter" constant="true"/>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7669) Misleading description of identity-realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7669?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7669:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Misleading description of identity-realm
> ----------------------------------------
>
> Key: WFLY-7669
> URL: https://issues.jboss.org/browse/WFLY-7669
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Tymel
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> There is a misleading description of {{identity-realm}} in DMR [1]. It says _"A security realm definition where identities are represented in the management model."_ whereas an XSD documentation says _"Realm definition for a realm which contains a single pre-defined identity."_.
> In general, the XSD description looks clearer to me. Moreover, the {{identities}} word may be misleading since {{identity-realm}}'s purpose is to _"to store one identity, with one attribute and no credential"_ [3]. Thus I would suggest to also change the description of {{attribute-values}} from
> _"The values associated with the identities attribute."_ to something like _"The values associated with the identity attributes."_
> Suggestions for improvement:
> * Change description {{identity-realm}} according to XSD
> * Change description of {{attribute-values}} attr (in both DMR and XSD)
> * to consider: unify descriptions in XSD and DMR
> [1] /subsystem=elytron/identity-realm=somerealm:read-resource-description
> [2] https://github.com/wildfly-security/elytron-subsystem/blob/master/src/mai...
> [3] HipChats's WildFly Elytron chat room on Nov 21
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7676) Description of Elytron oauth2-introspection resource is copy/pasted from jwt
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7676?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7676:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Description of Elytron oauth2-introspection resource is copy/pasted from jwt
> ----------------------------------------------------------------------------
>
> Key: WFLY-7676
> URL: https://issues.jboss.org/browse/WFLY-7676
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
> Fix For: 11.0.0.Alpha1
>
>
> Description of {{oauth2-introspection}} resource from Elytron {{token-realm}} is copy/pasted from description of {{jwt}}.
> It is similar as WFLY-7573, but its description (and also its linked fix) talks only about description of attributes. This Jira is related to description of whole resource which currently says:
> "A token validator to be used in conjunction with a token-based realm that handles security tokens based on the JWT/JWS standard."
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7687) Authentication based on certificates does not work in Elytron with Undertow
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7687?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7687:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
> Key: WFLY-7687
> URL: https://issues.jboss.org/browse/WFLY-7687
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Tymel
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
> Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> ... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [1] https://docs.jboss.org/author/display/WFLY/Elytron+Examples#ElytronExampl...
> [2] https://docs.jboss.org/author/display/WFLY/Elytron+Examples#ElytronExampl...
> [3] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7779) ReAuth does not work with Elytron
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7779?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7779:
----------------------------------------
[~honza889] I think we may end up with a variety of issues being raised specifically for the testsuite work - could we please choose and use a common label that can be applied to all issues so they can be filtered even if they end up being across multiple projects.
> ReAuth does not work with Elytron
> ---------------------------------
>
> Key: WFLY-7779
> URL: https://issues.jboss.org/browse/WFLY-7779
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Darran Lofthouse
>
> Following way of change identity from servlet does not work:
> {code:java}
> LoginContext lc = getCLMLoginContext(username, password);
> lc.login();
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months