[JBoss JIRA] (WFLY-7994) Legacy Kerberos in management, EAP search for HTTPS/localhost ticket
by Martin Choma (JIRA)
Martin Choma created WFLY-7994:
----------------------------------
Summary: Legacy Kerberos in management, EAP search for HTTPS/localhost ticket
Key: WFLY-7994
URL: https://issues.jboss.org/browse/WFLY-7994
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
Accessing management interface secured by Kerberos + TLS causes EAP requests from KDC ticket HTTPS/localhost. Which was not necessary in EAP 7.0 and it worked fine with HTTP/localhost service name
{code:title=server.log}
14:20:19,321 TRACE [org.jboss.as.domain.management.security] (management task-7) No mapping for name 'https/localhost.localdomain' to KeytabService, attempting to use host only match.
14:20:19,322 TRACE [org.jboss.as.domain.management.security] (management task-7) Selected KeytabService with principal 'HTTP/localhost.localdomain(a)JBOSS.ORG' for host 'localhost.localdomain'
14:20:19,322 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,323 INFO [stdout] (management task-7) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,524 WARN [org.apache.directory.server.protocol.shared.kerberos.StoreUtils] (NioDatagramAcceptor-3) No server entry found for kerberos principal name HTTPS/localhost.localdomain(a)JBOSS.ORG
14:20:19,524 WARN [org.apache.directory.server.KERBEROS_LOG] (NioDatagramAcceptor-3) No server entry found for kerberos principal name HTTPS/localhost.localdomain(a)JBOSS.ORG
14:20:19,524 WARN [org.apache.directory.server.kerberos.protocol.KerberosProtocolHandler] (NioDatagramAcceptor-3) Server not found in Kerberos database (7)
14:20:19,525 WARN [org.apache.directory.server.KERBEROS_LOG] (NioDatagramAcceptor-3) Server not found in Kerberos database (7)
14:20:19,528 WARN [org.apache.http.impl.auth.HttpAuthenticator] (main) NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - Server not found in Kerberos database))
14:20:19,532 TRACE [org.jboss.as.domain.management.security] (management task-9) No mapping for name 'https/localhost.localdomain' to KeytabService, attempting to use host only match.
14:20:19,532 TRACE [org.jboss.as.domain.management.security] (management task-9) Selected KeytabService with principal 'HTTP/localhost.localdomain(a)JBOSS.ORG' for host 'localhost.localdomain'
14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
14:20:19,533 INFO [stdout] (management task-9) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.2269988831769483313.keytab for HTTP/localhost.localdomain(a)JBOSS.ORG
[Krb5LoginModule]: Entering logout
[Krb5LoginModule]: logged out Subject
{code}
Also see network dump krb_https_management.pcap in attachement, where TGS-REQ for HTTPS/localhost is captured.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7993) Legacy Kerberos in management, unable to configure fallback authentication.
by Martin Choma (JIRA)
Martin Choma created WFLY-7993:
----------------------------------
Summary: Legacy Kerberos in management, unable to configure fallback authentication.
Key: WFLY-7993
URL: https://issues.jboss.org/browse/WFLY-7993
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore.
In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use.
{code:title=EAP 7.0}
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="FallBackKerberosRealm"
X-Frame-Options: SAMEORIGIN
Content-Length: 77
Content-Type: text/html
Date: Mon, 30 Jan 2017 11:02:45 GMT
<html><head><title>Error</title></head><body>401 - Unauthorized</body></html>
{code}
In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic.
{code:title=EAP 7.1}
HTTP/1.1 401 Unauthorized
Connection: keep-alive
WWW-Authenticate: Negotiate
X-Frame-Options: SAMEORIGIN
Content-Length: 77
Content-Type: text/html
Date: Mon, 30 Jan 2017 11:01:28 GMT
<html><head><title>Error</title></head><body>401 - Unauthorized</body></html>
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7992) Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7992?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7992:
-----------------------------
Description:
WFCORE-2196 copies ClientCompatibilityUnitTestCase into core, and makes most of the code available in ClientCompatibilityUnitTestBase in testsuite/shared.
Once merged, WFLY's copy of ClientCompatibilityUnitTestCase should be adjusted to reuse the code from the shared class.
was:WFCORE-2196 copies
> Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7992
> URL: https://issues.jboss.org/browse/WFLY-7992
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> WFCORE-2196 copies ClientCompatibilityUnitTestCase into core, and makes most of the code available in ClientCompatibilityUnitTestBase in testsuite/shared.
> Once merged, WFLY's copy of ClientCompatibilityUnitTestCase should be adjusted to reuse the code from the shared class.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7992) Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7992?page=com.atlassian.jira.plugin.... ]
Kabir Khan moved WFCORE-2243 to WFLY-7992:
------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-7992 (was: WFCORE-2243)
Component/s: Domain Management
(was: Domain Management)
> Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7992
> URL: https://issues.jboss.org/browse/WFLY-7992
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> [3:44 PM] Kabir Khan: @DarranLofthouse I see this in the logs
> [3:44 PM] Kabir Khan: 2017-01-16 15:38:55,589 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
> 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)
> Caused by: java.lang.NoSuchMethodError: org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.setDefaultRealm(Ljava/lang/String;)Lorg/wildfly/security/auth/realm/LegacyPropertiesSecurityRealm$Builder;
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:187)
> at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:171)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> ... 3 more
> [3:44 PM] Kabir Khan: @BrianStansberry perhaps ClientCompatibilityUnitTestCase should be in core rather than full?
> [3:47 PM] Darran Lofthouse: @KabirKhan do we have any error as to why it is not up?
> [3:47 PM] Kabir Khan: Yes, the NoSuchErrorException
> [3:48 PM] Kabir Khan: umm :)
> [3:48 PM] Kabir Khan: I invented a new class
> [3:48 PM] Kabir Khan: NoSuchMethodError
> [3:48 PM] Kabir Khan: I pasted it above my mention of Brian
> [3:49 PM] Kabir Khan: So PropertiesRealmDefinition is calling a non-existent setDefaultRealm() method on LegacyPropertiesSecurityRealm's builder
> [3:49 PM] Darran Lofthouse: @KabirKhan if the method doesn't exist that means the wrong Elytron version is being used
> [3:50 PM] Kabir Khan: Argh
> [3:50 PM] Kabir Khan: I released core without your PR merged
> [3:50 PM] Darran Lofthouse: LOL - that would explain how the wrong Elytron version is being used ;-)
> [3:51 PM] Kabir Khan: ok, I'll try again
> [3:53 PM] Brian Stansberry: @KabirKhan perhaps but I bet there was a reason we didn't move it
> [3:55 PM] Kabir Khan: On the positive side, it is not the night before the release
> [3:58 PM] Brian Stansberry: @KabirKhan if there is such a reason I don't see it in the code for that test
> [3:58 PM] Kabir Khan: yeah, me neither
> [3:59 PM] Kabir Khan: @BrianStansberry I'll rerelease core to fix my previous error
> [3:59 PM] Kabir Khan: but can look into this
> [3:59 PM] Kabir Khan: I'll create a Jira so I remember
> [3:59 PM] Brian Stansberry: @KabirKhan thanks
> [4:00 PM] Kabir Khan: although, I guess in this case it was a good thing
> [4:00 PM] Brian Stansberry: @KabirKhan tangent: do you recall if in the mixed domain tests we have the test driver invoke any ops against the legacy slave?
> [4:00 PM] Kabir Khan: this was what alerted e to the problem
> [4:00 PM] Kabir Khan: @BrianStansberry not off the top of my head, but I'd guess there should be at least some direct read-resource calls
> [4:00 PM] Brian Stansberry: @KabirKhan ah, you mean it was something in the full config that failed, that wouldn't be in core?
> [4:01 PM] Brian Stansberry: i'd say we shouldn't move that test but instead copy it
> [4:01 PM] Kabir Khan: @BrianStansberry there was an update to the elytron subsystem in full calling some stuff in Elytron
> [4:02 PM] Kabir Khan: that Elytron stuff wasn't there, because I had forgotten to merge the core PR that brought it in the Elytron upgrade
> [4:02 PM] Kabir Khan: so I saw NoSuchMethodErrors
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7992) Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7992?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7992:
-----------------------------
Description: WFCORE-2196 copies (was: [3:44 PM] Kabir Khan: @DarranLofthouse I see this in the logs
[3:44 PM] Kabir Khan: 2017-01-16 15:38:55,589 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
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)
Caused by: java.lang.NoSuchMethodError: org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.setDefaultRealm(Ljava/lang/String;)Lorg/wildfly/security/auth/realm/LegacyPropertiesSecurityRealm$Builder;
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:187)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:171)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
... 3 more
[3:44 PM] Kabir Khan: @BrianStansberry perhaps ClientCompatibilityUnitTestCase should be in core rather than full?
[3:47 PM] Darran Lofthouse: @KabirKhan do we have any error as to why it is not up?
[3:47 PM] Kabir Khan: Yes, the NoSuchErrorException
[3:48 PM] Kabir Khan: umm :)
[3:48 PM] Kabir Khan: I invented a new class
[3:48 PM] Kabir Khan: NoSuchMethodError
[3:48 PM] Kabir Khan: I pasted it above my mention of Brian
[3:49 PM] Kabir Khan: So PropertiesRealmDefinition is calling a non-existent setDefaultRealm() method on LegacyPropertiesSecurityRealm's builder
[3:49 PM] Darran Lofthouse: @KabirKhan if the method doesn't exist that means the wrong Elytron version is being used
[3:50 PM] Kabir Khan: Argh
[3:50 PM] Kabir Khan: I released core without your PR merged
[3:50 PM] Darran Lofthouse: LOL - that would explain how the wrong Elytron version is being used ;-)
[3:51 PM] Kabir Khan: ok, I'll try again
[3:53 PM] Brian Stansberry: @KabirKhan perhaps but I bet there was a reason we didn't move it
[3:55 PM] Kabir Khan: On the positive side, it is not the night before the release
[3:58 PM] Brian Stansberry: @KabirKhan if there is such a reason I don't see it in the code for that test
[3:58 PM] Kabir Khan: yeah, me neither
[3:59 PM] Kabir Khan: @BrianStansberry I'll rerelease core to fix my previous error
[3:59 PM] Kabir Khan: but can look into this
[3:59 PM] Kabir Khan: I'll create a Jira so I remember
[3:59 PM] Brian Stansberry: @KabirKhan thanks
[4:00 PM] Kabir Khan: although, I guess in this case it was a good thing
[4:00 PM] Brian Stansberry: @KabirKhan tangent: do you recall if in the mixed domain tests we have the test driver invoke any ops against the legacy slave?
[4:00 PM] Kabir Khan: this was what alerted e to the problem
[4:00 PM] Kabir Khan: @BrianStansberry not off the top of my head, but I'd guess there should be at least some direct read-resource calls
[4:00 PM] Brian Stansberry: @KabirKhan ah, you mean it was something in the full config that failed, that wouldn't be in core?
[4:01 PM] Brian Stansberry: i'd say we shouldn't move that test but instead copy it
[4:01 PM] Kabir Khan: @BrianStansberry there was an update to the elytron subsystem in full calling some stuff in Elytron
[4:02 PM] Kabir Khan: that Elytron stuff wasn't there, because I had forgotten to merge the core PR that brought it in the Elytron upgrade
[4:02 PM] Kabir Khan: so I saw NoSuchMethodErrors)
> Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7992
> URL: https://issues.jboss.org/browse/WFLY-7992
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
>
> WFCORE-2196 copies
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2243) Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-2243:
----------------------------------
Summary: Rework ClientCompatibilityUnitTestCase to use ClientCompatibilityUnitTestBase from core testsuite/share
Key: WFCORE-2243
URL: https://issues.jboss.org/browse/WFCORE-2243
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Kabir Khan
Assignee: Kabir Khan
[3:44 PM] Kabir Khan: @DarranLofthouse I see this in the logs
[3:44 PM] Kabir Khan: 2017-01-16 15:38:55,589 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
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)
Caused by: java.lang.NoSuchMethodError: org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.setDefaultRealm(Ljava/lang/String;)Lorg/wildfly/security/auth/realm/LegacyPropertiesSecurityRealm$Builder;
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:187)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:171)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
... 3 more
[3:44 PM] Kabir Khan: @BrianStansberry perhaps ClientCompatibilityUnitTestCase should be in core rather than full?
[3:47 PM] Darran Lofthouse: @KabirKhan do we have any error as to why it is not up?
[3:47 PM] Kabir Khan: Yes, the NoSuchErrorException
[3:48 PM] Kabir Khan: umm :)
[3:48 PM] Kabir Khan: I invented a new class
[3:48 PM] Kabir Khan: NoSuchMethodError
[3:48 PM] Kabir Khan: I pasted it above my mention of Brian
[3:49 PM] Kabir Khan: So PropertiesRealmDefinition is calling a non-existent setDefaultRealm() method on LegacyPropertiesSecurityRealm's builder
[3:49 PM] Darran Lofthouse: @KabirKhan if the method doesn't exist that means the wrong Elytron version is being used
[3:50 PM] Kabir Khan: Argh
[3:50 PM] Kabir Khan: I released core without your PR merged
[3:50 PM] Darran Lofthouse: LOL - that would explain how the wrong Elytron version is being used ;-)
[3:51 PM] Kabir Khan: ok, I'll try again
[3:53 PM] Brian Stansberry: @KabirKhan perhaps but I bet there was a reason we didn't move it
[3:55 PM] Kabir Khan: On the positive side, it is not the night before the release
[3:58 PM] Brian Stansberry: @KabirKhan if there is such a reason I don't see it in the code for that test
[3:58 PM] Kabir Khan: yeah, me neither
[3:59 PM] Kabir Khan: @BrianStansberry I'll rerelease core to fix my previous error
[3:59 PM] Kabir Khan: but can look into this
[3:59 PM] Kabir Khan: I'll create a Jira so I remember
[3:59 PM] Brian Stansberry: @KabirKhan thanks
[4:00 PM] Kabir Khan: although, I guess in this case it was a good thing
[4:00 PM] Brian Stansberry: @KabirKhan tangent: do you recall if in the mixed domain tests we have the test driver invoke any ops against the legacy slave?
[4:00 PM] Kabir Khan: this was what alerted e to the problem
[4:00 PM] Kabir Khan: @BrianStansberry not off the top of my head, but I'd guess there should be at least some direct read-resource calls
[4:00 PM] Brian Stansberry: @KabirKhan ah, you mean it was something in the full config that failed, that wouldn't be in core?
[4:01 PM] Brian Stansberry: i'd say we shouldn't move that test but instead copy it
[4:01 PM] Kabir Khan: @BrianStansberry there was an update to the elytron subsystem in full calling some stuff in Elytron
[4:02 PM] Kabir Khan: that Elytron stuff wasn't there, because I had forgotten to merge the core PR that brought it in the Elytron upgrade
[4:02 PM] Kabir Khan: so I saw NoSuchMethodErrors
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2242) Broken logout from Web console when is used Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2242?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2242:
-------------------------------------
Description:
When we use EAP with Elytron (standalone-elytron.xml configuration file) we aren't able to logout from Web console.
With legacy security realms everything is ok.
*How to reproduce*
* start EAP *standalone.sh -c=standalone-elytron.xml*
* log in to Web console on http://localhost:9990
* invoke logout
You will get this url http://localhost:9990/logout
{code}
404 - Not Found
{code}
was:
When we use EAP with Elytron (standalone-elytron.xml configuration file) we aren't able to logout from Web console.
With PicketBox is everything ok.
*How to reproduce*
* start EAP *standalone.sh -c=standalone-elytron.xml*
* log in to Web console on http://localhost:9990
* invoke logout
You will get this url http://localhost:9990/logout
{code}
404 - Not Found
{code}
> Broken logout from Web console when is used Elytron subsystem
> -------------------------------------------------------------
>
> Key: WFCORE-2242
> URL: https://issues.jboss.org/browse/WFCORE-2242
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> When we use EAP with Elytron (standalone-elytron.xml configuration file) we aren't able to logout from Web console.
> With legacy security realms everything is ok.
> *How to reproduce*
> * start EAP *standalone.sh -c=standalone-elytron.xml*
> * log in to Web console on http://localhost:9990
> * invoke logout
> You will get this url http://localhost:9990/logout
> {code}
> 404 - Not Found
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months