[JBoss JIRA] (WFCORE-1882) Deal with WFCORE-1052 functionality in the HA DC case
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1882?page=com.atlassian.jira.plugi... ]
Ken Wills reassigned WFCORE-1882:
---------------------------------
Assignee: Ken Wills
> Deal with WFCORE-1052 functionality in the HA DC case
> -----------------------------------------------------
>
> Key: WFCORE-1882
> URL: https://issues.jboss.org/browse/WFCORE-1882
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
>
> WFCORE-1052 adds the ability to reload a process to a different config file from what it is currently running. That includes the domain-wide config file if the reloading process is a master HC.
> I don't think we want to support this in a WFCORE-338 scenario, as it amounts to a mechanism to force a different domain-wide config into the domain. I think we should have a more specific, controlled mechanism for that.
> Once WFCORE-1881 is implemented HostProcessReloadHandler can check LocalHostControllerInfo to see if its running in a CDC. Note that this issue may have implications on the design of WFCORE-1881. That is, it may not be the case that if LHCI.isMaster() is true then LHCI.isCandidateDomainController() is true. Perhaps an HC configured in the EAP 7.0 and earlier style could be a master but not a CDC. For such an HC the WFCORE-1052 functionality could be available.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-693) Elytron SPNEGO "continuation required" situation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-693?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved JBEAP-6645 to ELY-693:
---------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-693 (was: JBEAP-6645)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Authentication Mechanisms
(was: Security)
Affects Version/s: (was: 7.1.0.DR7)
> Elytron SPNEGO "continuation required" situation
> ------------------------------------------------
>
> Key: ELY-693
> URL: https://issues.jboss.org/browse/ELY-693
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> I have problem to achieve this scenario with elytron:
> # Client sends non kerberos OID mechanism as most preferred with non kerberos ticket
> # Server response with "continuation required"
> # Client sends kerberos ticket
> # Server response with 401 instead of 200
> Actually, it is scenario tested in [1]. It worked correctly in EAP 7.0 . Also works with elytron when client sends non-kerberos OID mechanism with kerberos ticket.
> Problem as I see is that SpnegoAuthenticationMechanism:
> # Creates {{gssContext}} with first provided ticket (non-kerberos) and sends "continuation required"
> # Client provide proper kerberos ticket, but that anyway leads to 401 bare challenge, because {{gssContext}} was already created in first step and is not tried to make again.
> Setting to critical as it behaves differently compared to EAP 7.0 and IMHO it doesn't comply to spec [2]. Similar error was resolved in EAP 7.0 (JBEAP-3709) as blocker because customer case existed for that.
> [1] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13d...
> [2] https://tools.ietf.org/html/rfc4178
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-691) Elytron properties-realm is not compatible with legacy user property files
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-691?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-691:
-----------------------------
Steps to Reproduce:
For trying how it works in legacy security solution:
1) add following to {{$SERVER_HOME/standalone/configuration/mgmt-users.properties}}:
{code}
elytron:password
!elytron=password
elytronumlautöäü=password
elytron用戶=password
backslash\\=password
backslash\\inthemiddle=password
dn\=elytron,dc\=wildfly,dc\=org=password
elytron1=pass=word
elytron2=password\\
elytron3=pass\\word
elytron4=passwordWithumlautöäü
elytron5=用戶
{code}
2) configure ManagementRealm to use plain-text password:
{code}
/core-service=management/security-realm=ManagementRealm/authentication=properties:write-attribute(name=plain-text,value=true)
{code}
3) remove local authentication:
{code}
/core-service=management/security-realm=ManagementRealm/authentication=local:remove()
{code}
4) Try to login to jboss-cli with users mentioned in this JIRA description -> all pass (except {{!elytron/password}} which correctly fail)
For reproduction this issue in Elytron, use related tests from {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealmTest}} in Elytron unit tests.
was:
For trying how it works in legacy security solution:
1) add following to {{$SERVER_HOME/standalone/configuration/mgmt-users.properties}}:
{code}
elytron:password
!elytron=password
elytronumlautöäü=password
elytron用戶=password
backslash\\=password
backslash\\inthemiddle=password
dn\=elytron,dc\=wildfly,dc\=org=password
elytron1=pass=word
elytron2=password\\
elytron3=pass\\word
elytron4=passwordWithumlautöäü
elytron5=用戶
{code}
2) configure ManagementRealm to use plain-text password:
{code}
/core-service=management/security-realm=ManagementRealm/authentication=properties:write-attribute(name=plain-text,value=true)
{code}
3) remove local authentication:
{code}
/core-service=management/security-realm=ManagementRealm/authentication=local:remove()
{code}
4) Try to login to jboss-cli with users mentioned in this JIRA description -> all pass (except {{!elytron/password}} which correctly fail)
> Elytron properties-realm is not compatible with legacy user property files
> --------------------------------------------------------------------------
>
> Key: ELY-691
> URL: https://issues.jboss.org/browse/ELY-691
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta11
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
> Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
> {code}
> elytron:password // results to username elytron with password password
> elytronumlautöäü=password // results to username elytronumlautöäü with password password
> elytron用戶=password // results to username elytron用戶 with password password
> backslash\\=password // results to username backslash\ with password password
> backslash\\inthemiddle=password // results to username backslash\inthemiddle with password password
> dn\=elytron,dc\=wildfly,dc\=org=password // results to username dn=elytron,dc=wildfly,dc=org with password password
> elytron1=pass=word // results to username elytron1 with password pass=word - covered by JBEAP-6581
> elytron2=password\\ // results to username elytron2 with password password\
> elytron3=pass\\word // results to username elytron3 with password pass\word
> elytron4=passwordWithumlautöäü // results to username elytron4 with password passwordWithumlautöäü
> elytron5=用戶 // results to username elytron5 with password 用戶
> {code}
> Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-691) Elytron properties-realm is not compatible with legacy user property files
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-691:
--------------------------------
Summary: Elytron properties-realm is not compatible with legacy user property files
Key: ELY-691
URL: https://issues.jboss.org/browse/ELY-691
Project: WildFly Elytron
Issue Type: Bug
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
{code}
elytron:password // results to username elytron with password password
elytronumlautöäü=password // results to username elytronumlautöäü with password password
elytron用戶=password // results to username elytron用戶 with password password
backslash\\=password // results to username backslash\ with password password
backslash\\inthemiddle=password // results to username backslash\inthemiddle with password password
dn\=elytron,dc\=wildfly,dc\=org=password // results to username dn=elytron,dc=wildfly,dc=org with password password
elytron1=pass=word // results to username elytron1 with password pass=word - covered by JBEAP-6581
elytron2=password\\ // results to username elytron2 with password password\
elytron3=pass\\word // results to username elytron3 with password pass\word
elytron4=passwordWithumlautöäü // results to username elytron4 with password passwordWithumlautöäü
elytron5=用戶 // results to username elytron5 with password 用戶
{code}
Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-691) Elytron properties-realm is not compatible with legacy user property files
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-691?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-691:
-----------------------------
Affects Version/s: 1.1.0.Beta11
> Elytron properties-realm is not compatible with legacy user property files
> --------------------------------------------------------------------------
>
> Key: ELY-691
> URL: https://issues.jboss.org/browse/ELY-691
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta11
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> When users properties file (e.g. mgmt-users.properties) used by legacy properties security realm is taken and used with Elytron properties-realm (backed by {{org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm}}) then there exist username/password combinations which do not works correctly.
> Following scenarios which uses mentioned below username/password work correctly for properties file used by legacy solution and do not work for Elytron:
> {code}
> elytron:password // results to username elytron with password password
> elytronumlautöäü=password // results to username elytronumlautöäü with password password
> elytron用戶=password // results to username elytron用戶 with password password
> backslash\\=password // results to username backslash\ with password password
> backslash\\inthemiddle=password // results to username backslash\inthemiddle with password password
> dn\=elytron,dc\=wildfly,dc\=org=password // results to username dn=elytron,dc=wildfly,dc=org with password password
> elytron1=pass=word // results to username elytron1 with password pass=word - covered by JBEAP-6581
> elytron2=password\\ // results to username elytron2 with password password\
> elytron3=pass\\word // results to username elytron3 with password pass\word
> elytron4=passwordWithumlautöäü // results to username elytron4 with password passwordWithumlautöäü
> elytron5=用戶 // results to username elytron5 with password 用戶
> {code}
> Also '!' can be used for comments. It means that {{!elytron=password}} should not be considered as user {{!elytron}} but as comment.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (ELY-690) NPE in elytron SPNEGO implementation in exceptional states
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-690?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7343 to ELY-690:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-690 (was: WFLY-7343)
Component/s: Authentication Mechanisms
(was: Security)
Affects Version/s: (was: 11.0.0.Alpha1)
> NPE in elytron SPNEGO implementation in exceptional states
> ----------------------------------------------------------
>
> Key: ELY-690
> URL: https://issues.jboss.org/browse/ELY-690
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> Http response code 500 + excpetion in server log:
> {code}
> 21:40:40,640 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/secure/index.jsp: java.lang.NullPointerException
> at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.authorizeEstablishedContext(SpnegoAuthenticationMechanism.java:177)
> at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:128)
> 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.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 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.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> 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}
> I have hit this in two situations so far
> * accessing with kerberos ticket from another realm. E.g. application server is set for realm JBOSS.ORG, but client is jduke(a)REDHAT.COM
> ** For this situation is http response code 500 disputable, as it could be viewed as problem of client. Client can change ticket and authentication can be performed just fine.
> * misconfiguration e.g. wrong kdc in krb5.conf
> Provide some meaningful error message.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months