[JBoss JIRA] (LOGMGR-152) Add server and process name & id fields to log record
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-152?page=com.atlassian.jira.plugin... ]
James Perkins reassigned LOGMGR-152:
------------------------------------
Fix Version/s: 2.1.0.Beta1
Assignee: David Lloyd
Resolution: Done
> Add server and process name & id fields to log record
> -----------------------------------------------------
>
> Key: LOGMGR-152
> URL: https://issues.jboss.org/browse/LOGMGR-152
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Components: core
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 2.1.0.Beta1
>
>
> In order to support aggregation of log records with some awareness of origin, we would need server name and process name and id arguments on ExtLogRecord.
> The server name is a string field which contains the host name of the log record producer. The default value for this field would be {{org.wildfly.common.net.HostName#getHostName()}}. If the field is not present on deserialize, "<unknown>" could be used.
> The process name is a string field which contains the name of the process. The default value for this field could be extracted from the first part of the {{sun.java.command}} system property. It would be configurable via system property, e.g. {{jboss.logmanager.process.name}} or something. If the field is not present on deserialize, "<unknown>" could be used.
> The process ID field is a long field that contains the ID of the process. The value of this field should be set from ProcessHandle.current().pid() on Java 9. On Java 8 and earlier, you can use {{ManagementFactory.getRuntimeMXBean().getName()}} and parse the numeric data up to the {{@}} symbol. If the data does not parse, or the field is not present on deserialize, -1L should be used to indicate an unknown PID.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2732) Elytron - it should also be possible to store OTP algorithm on security realm level
by Josef Cacek (JIRA)
Josef Cacek created WFCORE-2732:
-----------------------------------
Summary: Elytron - it should also be possible to store OTP algorithm on security realm level
Key: WFCORE-2732
URL: https://issues.jboss.org/browse/WFCORE-2732
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Critical
It should be possible to store OTP algorithm name on security realm level too.
Using of the OTP SASL mechanism requires modifiable realm and currently only ldap-realm integration is finished.
The ldap-realm now requires to store the algorithm name into an LDAP attribute together with the rest of OTP configuration (seed, hash, sequence), but this can be limiting (or space vasting) when the algorithm is the same for all users in the realm. There should be a possibility to configure the OTP algorithm name also on the realm level and share it for users. Make it an alternative for {{ldap-realm.identity-mapping.otp-credential-mapper.algorithm-from}} configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2731) Slave hosts with default host-slave.xml configuration are not able to connect to master host with default host-master.xml configuration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2731?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-10567 to WFCORE-2731:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2731 (was: JBEAP-10567)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Security
(was: Domain Management)
(was: Security)
Affects Version/s: 3.0.0.Beta1
(was: 7.1.0.DR14)
Affects Testing: (was: Regression)
> Slave hosts with default host-slave.xml configuration are not able to connect to master host with default host-master.xml configuration
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2731
> URL: https://issues.jboss.org/browse/WFCORE-2731
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 3.0.0.Beta1
> Reporter: Michal Jurc
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: eap71_alpha
>
> Upon attempting to start a slave host with default {{host-slave.xml}} connecting to master host with default {{host-master.xml}}, the following error is produced and slave will not boot:
> {code}[mjurc@tigris 7.1.0.DR14]$ ./hc1/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=10099 -Djboss.host.name=HC1
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/mjurc/testing/eap/7.1.0.DR14/hc1
> JAVA: /usr/java/latest/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 09:18:32,658 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6-redhat-1
> 09:18:32,839 INFO [org.jboss.as.process.Host Controller.status] (main) WFLYPC0018: Starting process 'Host Controller'
> [Host Controller] 09:18:33,269 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6-redhat-1
> [Host Controller] 09:18:33,565 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1
> [Host Controller] 09:18:33,617 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta9-redhat-1) starting
> [Host Controller] 09:18:34,286 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=hc1/core-service=management/management-interface=native-interface' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [Host Controller] 09:18:34,288 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [Host Controller] 09:18:34,345 INFO [org.wildfly.security] (Controller Boot Thread) ELY00001: WildFly Elytron version 1.1.0.Beta31-redhat-1
> [Host Controller] 09:18:34,377 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.5.0.Beta2-redhat-1
> [Host Controller] 09:18:34,385 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.5.0.Beta2-redhat-1
> [Host Controller] 09:18:34,438 INFO [org.jboss.as.patching] (MSC service thread 1-7) WFLYPAT0050: JBoss EAP cumulative patch ID is: base, one-off patches include: none
> [Host Controller] 09:18:34,449 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 5.0.0.Beta19-redhat-1
> [Host Controller] 09:18:34,469 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-8) WFLYDM0111: Keystore /home/mjurc/testing/eap/7.1.0.DR14/hc1/domain/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> [Host Controller] 09:18:34,519 INFO [org.jboss.as.remoting] (MSC service thread 1-7) WFLYRMT0001: Listening on 127.0.0.1:10099
> [Host Controller] 09:18:34,848 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://127.0.0.1:9999: java.lang.IllegalStateException: WFLYHC0043: Unable to connect due to authentication failure.
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.rethrowIrrecoverableConnectionFailures(RemoteDomainConnectionService.java:674)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.register(RemoteDomainConnectionService.java:293)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.connectToDomainMaster(DomainModelControllerService.java:918)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:672)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:337)
> [Host Controller] at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> [Host Controller] JBOSS-LOCAL-USER: javax.security.sasl.SaslException: Server rejected authentication
> [Host Controller] DIGEST-MD5: javax.security.sasl.SaslException: Server rejected authentication
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:108)
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:395)
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:241)
> [Host Controller] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> [Host Controller] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> [Host Controller] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> [Host Controller] at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> [Host Controller] at ...asynchronous invocation...(Unknown Source)
> [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:465)
> [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:427)
> [Host Controller] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:415)
> [Host Controller] at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:177)
> [Host Controller] at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:113)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.lambda$openConnection$0(RemoteDomainConnection.java:223)
> [Host Controller] at org.wildfly.common.context.Contextual.runExceptionAction(Contextual.java:108)
> [Host Controller] at org.wildfly.security.auth.client.AuthenticationContext.run(AuthenticationContext.java:296)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.openConnection(RemoteDomainConnection.java:223)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$InitialConnectTask.connect(RemoteDomainConnection.java:592)
> [Host Controller] at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.connect(RemoteDomainConnection.java:147)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.register(RemoteDomainConnectionService.java:288)
> [Host Controller] ... 4 more
> [Host Controller] Suppressed: javax.security.sasl.SaslException: Server rejected authentication
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:716)
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:560)
> [Host Controller] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> [Host Controller] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> [Host Controller] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> [Host Controller] at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> [Host Controller] Suppressed: javax.security.sasl.SaslException: Server rejected authentication
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:716)
> [Host Controller] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.handleEvent(ClientConnectionOpenListener.java:560)
> [Host Controller] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> [Host Controller] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> [Host Controller] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> [Host Controller] at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
> [Host Controller]
> [Host Controller] 09:18:34,849 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
> [Host Controller] 09:18:34,849 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
> [Host Controller] 09:18:34,850 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
> [Host Controller] 09:18:34,867 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta9-redhat-1) stopped in 13ms
> [Host Controller]
> 09:18:35,188 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) WFLYPC0011: Process 'Host Controller' finished with an exit status of 99
> 09:18:35,189 INFO [org.jboss.as.process] (Thread-8) WFLYPC0017: Shutting down process controller
> 09:18:35,190 INFO [org.jboss.as.process] (Thread-8) WFLYPC0016: All processes finished; exiting
> {code}
> This issue renders managed domain unusable out of the box. This is a regression introduced in JBoss EAP 7.1.0.DR14.
> Master log with trace level logging for remoting subsystem is attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on ELY-1103:
----------------------------------
This is the more interesting part of the change actually: https://github.com/wildfly/wildfly/commit/c088a76f18512d56686e56ebed0aaaa...
> Special handling for JBOSS-LOCAL-USER server side authentication
> ----------------------------------------------------------------
>
> Key: ELY-1103
> URL: https://issues.jboss.org/browse/ELY-1103
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, SASL
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta39
>
>
> If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity.
> With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem.
> While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity.
> If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested.
> Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on ELY-1103:
----------------------------------
OK. I did end up making the following change to the CLI a few weeks ago, which might of use as a reference: https://github.com/wildfly/wildfly/commit/f0d8594f7aa7c47a7fb80f1205a514e...
> Special handling for JBOSS-LOCAL-USER server side authentication
> ----------------------------------------------------------------
>
> Key: ELY-1103
> URL: https://issues.jboss.org/browse/ELY-1103
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, SASL
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta39
>
>
> If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity.
> With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem.
> While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity.
> If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested.
> Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on ELY-1103:
---------------------------------------
Just to clarify: slave HCs have always had their management name as their default identity, i.e. the one that is used if no "username" is explicitly configured. That identity must be valid in the DC-side realm when local auth is not configured, or of course for the more usual case where the slave isn't on the same machine. Whatever has changed is in the way the local mechanism is being handled on the slave side, such that that identity is being presented via the JBOSS-LOCAL-USER mechanism whereas previous version slaves don't present it.
Letting the user explicitly configuring the username used by the slave was a way to make things easier by not requiring a separate entry in the realm for each slave. Configuring it wasn't meant to be required to get non-local-auth to work, not if your realm has entries for all your slaves.
I'll investigate what's changing on the slave side in the slave this is handled, keeping what you wrote in the description here about callbacks and handlers in mind as something to keep an eye out for.
> Special handling for JBOSS-LOCAL-USER server side authentication
> ----------------------------------------------------------------
>
> Key: ELY-1103
> URL: https://issues.jboss.org/browse/ELY-1103
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, SASL
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta39
>
>
> If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity.
> With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem.
> While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity.
> If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested.
> Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on ELY-1103:
----------------------------------
Long term though we *should* require slave HCs to have identities, probably, but that's a different discussion...
> Special handling for JBOSS-LOCAL-USER server side authentication
> ----------------------------------------------------------------
>
> Key: ELY-1103
> URL: https://issues.jboss.org/browse/ELY-1103
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, SASL
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta39
>
>
> If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity.
> With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem.
> While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity.
> If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested.
> Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on ELY-1103:
----------------------------------
Yeah I think that continuing to do what we've done in the past (presenting an empty authentication ID from slave HCs) is a good idea. I'm not sure why we would have started presenting the management name as the client ID; probably it was thought that some default had to be used, and that one was as good as any. But I think changing it back should be harmless.
> Special handling for JBOSS-LOCAL-USER server side authentication
> ----------------------------------------------------------------
>
> Key: ELY-1103
> URL: https://issues.jboss.org/browse/ELY-1103
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, SASL
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta39
>
>
> If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity.
> With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem.
> While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity.
> If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested.
> Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2673) HTTP redirect if both http and https socket-binding is configured for http-interface
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2673?page=com.atlassian.jira.plugi... ]
Martin Choma updated WFCORE-2673:
---------------------------------
Forum Reference: https://developer.jboss.org/message/971328?et=watches.email.thread#971328
> HTTP redirect if both http and https socket-binding is configured for http-interface
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-2673
> URL: https://issues.jboss.org/browse/WFCORE-2673
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
>
> In case when both http and https socket-binding is configured for management http-interface and http port is accessed then server tries to redirect automatically to https port. Access http is not possible.
> It causes that it is impossible to connect to http-interface with clients which do not supports https (even if http port is provided by application server), i.e. following ModelControllerClient is not able to connect to http-interface when both http and https socket-binding is configured:
> {code}
> ModelControllerClient client = ModelControllerClient.Factory
> .create(new ModelControllerClientConfiguration.Builder()
> .setProtocol("remote+http")
> .setPort(9990)
> .setHostName("localhost")
> .setConnectionTimeout(10000).build())
> {code}
> See:
> {code}
> curl -v -H 'Upgrade: jboss-remoting' http://localhost:9990
> * Rebuilt URL to: http://localhost:9990/
> * Hostname was NOT found in DNS cache
> * Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 9990 (#0)
> > GET / HTTP/1.1
> > User-Agent: curl/7.38.0
> > Host: localhost:9990
> > Accept: */*
> > Upgrade: jboss-remoting
> >
> < HTTP/1.1 302 Found
> < Connection: keep-alive
> < Location: https://localhost:9993/
> < Content-Length: 0
> < Date: Thu, 13 Apr 2017 11:59:56 GMT
> <
> * Connection #0 to host localhost left intact
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on ELY-1103:
---------------------------------------
Yesterday I was investigating JBEAP-10084 and the need for the must-be-removed workaround used to resolve JBEAP-9655. Both of these somewhat relate to this in that the JBOSS-LOCAL-USER mechanism is used, although those JIRAs relate to interaction with a legacy security realm. But while investigating I learned the relevant use cases so here's some information in case it's helpful:
1) The current CLI when authenticating presents an empty authenticationId. This results in LocalUserServer.defaultUser being used. That was "$local"; how that value for defaultUser got set I didn't research.
My guess is the way the CLI is written it doesn't prompt for a username/password until authenticating with an empty authenticationId fails. I didn't check.
2) I didn't try a previous release CLI to check if it was the same.
3) A current release slave HC provides an authenticationId that's the same as the slave's management name. This fails in an OOTB WildFly domain because the ManagementRealm is not configured with entries for the slaves. This is the cause of JBEAP-9655 and why the workaround of configuring the slave to use username="$local" works.
For a legacy security realm https://github.com/wildfly/wildfly-core/compare/master...bstansberry:loca... solves the problem of broken OOTB behavior. Changing the legacy security realm's standard local auth config to add allowed-users="*" would do the same thing. Perhaps figuring out how the CLI is able to present an empty authenticationId and having the intra-domain logic do the same would also solve it.
4) An EAP 7.0.x slave HC presents an empty authenticationId. I don't know why, but of course the client side logic is different in EAP 7.0.x. Because it does, a 7.0.x slave is able to authenticate, same as the CLI can.
5) I didn't try an EAP 6 slave.
My personal opinion on this is things in the management area that used to "just work" should continue to just work. If that means the client side should not present a non-empty authenticationId because elytron-based authentication is going to insist on finding that id, that's fair enough, but we'll need to make sure our clients try to present the empty id first. It seems that the CLI and previous release slave HCs do that.
> Special handling for JBOSS-LOCAL-USER server side authentication
> ----------------------------------------------------------------
>
> Key: ELY-1103
> URL: https://issues.jboss.org/browse/ELY-1103
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Server, SASL
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta39
>
>
> If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity.
> With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem.
> While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity.
> If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested.
> Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years