[JBoss JIRA] (LOGMGR-127) Module naming does does not support slots
by James Livingston (JIRA)
James Livingston created LOGMGR-127:
---------------------------------------
Summary: Module naming does does not support slots
Key: LOGMGR-127
URL: https://issues.jboss.org/browse/LOGMGR-127
Project: JBoss Log Manager
Issue Type: Bug
Reporter: James Livingston
AbstractPropertyConfiguration$ModuleFinder uses ModuleIdentifier.create() rather than fromString(), which means it does not support specifying the slot via "module:slot" and can only use the main slot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (ELY-374) Ambiguous application of CredentialCallback
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-374?page=com.atlassian.jira.plugin.sy... ]
David Lloyd edited comment on ELY-374 at 11/18/15 7:47 PM:
-----------------------------------------------------------
I think the main deciding factor on using a peer {{CredentialCallback}} versus a {{VerifyPeerTrustedCallback}} is, if you have a {{NameCallback}} which provides the peer name in advance, then use {{CredentialCallback}} (or {{EvidenceVerifyCallback}}), else {{VerifyPeerTrustedCallback}}.
What makes {{NameCallback}} special is that on the client side, it's used to query the local callback handler to get the name to send to the peer, i.e. it's a local name. On the server side, it is used to tell the callback handler what name the client is using, i.e. it's a peer name. There isn't a flag to distinguish the cases.
was (Author: dmlloyd):
I think the main deciding factor on using a peer {{CredentialCallback}} versus a {{VerifyPeerTrustedCallback}} is, if you have a {{NameCallback}} for the peer, then use {{CredentialCallback}} (or {{EvidenceVerifyCallback}}), else {{VerifyPeerTrustedCallback}}.
What makes {{NameCallback}} special is that on the client side, it's used to query the local callback handler to get the name to send to the peer, i.e. it's a local name. On the server side, it is used to tell the callback handler what name the client is using, i.e. it's a peer name. There isn't a flag to distinguish the cases.
> Ambiguous application of CredentialCallback
> -------------------------------------------
>
> Key: ELY-374
> URL: https://issues.jboss.org/browse/ELY-374
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms, Callbacks, SASL
> Reporter: David Lloyd
> Priority: Critical
> Fix For: 1.1.0.Beta3
>
>
> We have a problem where there is an ambiguous application of {{CredentialCallback}}.
> On the client, this callback is used to acquire the credential to use for outbound authentication. On the server, it is used in two ways:
> * For most authentication, it is used to acquire the credential that is used to verify the client identity.
> * For Entity authentication, it is used to acquire the credential that is used to identify the server to the client.
> The reason Entity can get away with this special behavior is that it uses the {{VerifyPeerTrustedCallback}} instead of {{CredentialCallbak}} for checking the peer. Unfortunately, it is not easy for a callback handler to know when {{CredentialCallback}} is being used for the host identity versus the authenticating user identity. This needs to be solved ASAP so that we can have server mechanisms that present a host identity as well as acquiring a credential for user authentication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (ELY-374) Ambiguous application of CredentialCallback
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-374?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-374:
---------------------------------
I think the main deciding factor on using a peer {{CredentialCallback}} versus a {{VerifyPeerTrustedCallback}} is, if you have a {{NameCallback}} for the peer, then use {{CredentialCallback}}, else {{VerifyPeerTrustedCallback}}.
What makes {{NameCallback}} special is that on the client side, it's used to query the local callback handler to get the name to send to the peer, i.e. it's a local name. On the server side, it is used to tell the callback handler what name the client is using, i.e. it's a peer name. There isn't a flag to distinguish the cases.
> Ambiguous application of CredentialCallback
> -------------------------------------------
>
> Key: ELY-374
> URL: https://issues.jboss.org/browse/ELY-374
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms, Callbacks, SASL
> Reporter: David Lloyd
> Priority: Critical
> Fix For: 1.1.0.Beta3
>
>
> We have a problem where there is an ambiguous application of {{CredentialCallback}}.
> On the client, this callback is used to acquire the credential to use for outbound authentication. On the server, it is used in two ways:
> * For most authentication, it is used to acquire the credential that is used to verify the client identity.
> * For Entity authentication, it is used to acquire the credential that is used to identify the server to the client.
> The reason Entity can get away with this special behavior is that it uses the {{VerifyPeerTrustedCallback}} instead of {{CredentialCallbak}} for checking the peer. Unfortunately, it is not easy for a callback handler to know when {{CredentialCallback}} is being used for the host identity versus the authenticating user identity. This needs to be solved ASAP so that we can have server mechanisms that present a host identity as well as acquiring a credential for user authentication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (ELY-374) Ambiguous application of CredentialCallback
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-374?page=com.atlassian.jira.plugin.sy... ]
David Lloyd edited comment on ELY-374 at 11/18/15 7:46 PM:
-----------------------------------------------------------
I think the main deciding factor on using a peer {{CredentialCallback}} versus a {{VerifyPeerTrustedCallback}} is, if you have a {{NameCallback}} for the peer, then use {{CredentialCallback}} (or {{EvidenceVerifyCallback}}), else {{VerifyPeerTrustedCallback}}.
What makes {{NameCallback}} special is that on the client side, it's used to query the local callback handler to get the name to send to the peer, i.e. it's a local name. On the server side, it is used to tell the callback handler what name the client is using, i.e. it's a peer name. There isn't a flag to distinguish the cases.
was (Author: dmlloyd):
I think the main deciding factor on using a peer {{CredentialCallback}} versus a {{VerifyPeerTrustedCallback}} is, if you have a {{NameCallback}} for the peer, then use {{CredentialCallback}}, else {{VerifyPeerTrustedCallback}}.
What makes {{NameCallback}} special is that on the client side, it's used to query the local callback handler to get the name to send to the peer, i.e. it's a local name. On the server side, it is used to tell the callback handler what name the client is using, i.e. it's a peer name. There isn't a flag to distinguish the cases.
> Ambiguous application of CredentialCallback
> -------------------------------------------
>
> Key: ELY-374
> URL: https://issues.jboss.org/browse/ELY-374
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms, Callbacks, SASL
> Reporter: David Lloyd
> Priority: Critical
> Fix For: 1.1.0.Beta3
>
>
> We have a problem where there is an ambiguous application of {{CredentialCallback}}.
> On the client, this callback is used to acquire the credential to use for outbound authentication. On the server, it is used in two ways:
> * For most authentication, it is used to acquire the credential that is used to verify the client identity.
> * For Entity authentication, it is used to acquire the credential that is used to identify the server to the client.
> The reason Entity can get away with this special behavior is that it uses the {{VerifyPeerTrustedCallback}} instead of {{CredentialCallbak}} for checking the peer. Unfortunately, it is not easy for a callback handler to know when {{CredentialCallback}} is being used for the host identity versus the authenticating user identity. This needs to be solved ASAP so that we can have server mechanisms that present a host identity as well as acquiring a credential for user authentication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (ELY-374) Ambiguous application of CredentialCallback
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-374?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-374:
---------------------------------
In any event, configuring a server-side local credential or set of credentials is something which should be done in a {{MechanismConfiguration}}.
> Ambiguous application of CredentialCallback
> -------------------------------------------
>
> Key: ELY-374
> URL: https://issues.jboss.org/browse/ELY-374
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms, Callbacks, SASL
> Reporter: David Lloyd
> Priority: Critical
> Fix For: 1.1.0.Beta3
>
>
> We have a problem where there is an ambiguous application of {{CredentialCallback}}.
> On the client, this callback is used to acquire the credential to use for outbound authentication. On the server, it is used in two ways:
> * For most authentication, it is used to acquire the credential that is used to verify the client identity.
> * For Entity authentication, it is used to acquire the credential that is used to identify the server to the client.
> The reason Entity can get away with this special behavior is that it uses the {{VerifyPeerTrustedCallback}} instead of {{CredentialCallbak}} for checking the peer. Unfortunately, it is not easy for a callback handler to know when {{CredentialCallback}} is being used for the host identity versus the authenticating user identity. This needs to be solved ASAP so that we can have server mechanisms that present a host identity as well as acquiring a credential for user authentication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (ELY-374) Ambiguous application of CredentialCallback
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-374?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-374:
---------------------------------
Here are some options:
# Add a field to {{CredentialCallback}} to designate local or peer credential, or perhaps client or server credential. In the Entity mechanism, use {{CredentialCallback}} on the client and server to acquire the local credential to use, and the general peer trust callback to verify the peer's public credential. On the client, only local credentials may be sensibly acquired, but on the server, either local or peer credentials might be acquired.
# Add a field to {{CredentialCallback}} as above, but stop using {{VerifyPeerTrustedCallback}} to verify the client, instead using a second (peer) {{CredentialCallback}} to acquire the user public credential and performing the validation within the mechanism. The {{VerifyPeerTrustedCallback}} (or its ELY-373 equivalent) would still be used on the client to verify the server.
# Add a {{LocalCredentialCallback}} which acquires the local credential. Use this credential on the server to acquire the host credential. Change the client to use this callback to acquire the user credential on the client. The server would continue to use {{CredentialCallback}} to acquire the user (peer) credential.
> Ambiguous application of CredentialCallback
> -------------------------------------------
>
> Key: ELY-374
> URL: https://issues.jboss.org/browse/ELY-374
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms, Callbacks, SASL
> Reporter: David Lloyd
> Priority: Critical
> Fix For: 1.1.0.Beta3
>
>
> We have a problem where there is an ambiguous application of {{CredentialCallback}}.
> On the client, this callback is used to acquire the credential to use for outbound authentication. On the server, it is used in two ways:
> * For most authentication, it is used to acquire the credential that is used to verify the client identity.
> * For Entity authentication, it is used to acquire the credential that is used to identify the server to the client.
> The reason Entity can get away with this special behavior is that it uses the {{VerifyPeerTrustedCallback}} instead of {{CredentialCallbak}} for checking the peer. Unfortunately, it is not easy for a callback handler to know when {{CredentialCallback}} is being used for the host identity versus the authenticating user identity. This needs to be solved ASAP so that we can have server mechanisms that present a host identity as well as acquiring a credential for user authentication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (ELY-374) Ambiguous application of CredentialCallback
by David Lloyd (JIRA)
David Lloyd created ELY-374:
-------------------------------
Summary: Ambiguous application of CredentialCallback
Key: ELY-374
URL: https://issues.jboss.org/browse/ELY-374
Project: WildFly Elytron
Issue Type: Bug
Components: Authentication Mechanisms, Callbacks, SASL
Reporter: David Lloyd
Priority: Critical
Fix For: 1.1.0.Beta3
We have a problem where there is an ambiguous application of {{CredentialCallback}}.
On the client, this callback is used to acquire the credential to use for outbound authentication. On the server, it is used in two ways:
* For most authentication, it is used to acquire the credential that is used to verify the client identity.
* For Entity authentication, it is used to acquire the credential that is used to identify the server to the client.
The reason Entity can get away with this special behavior is that it uses the {{VerifyPeerTrustedCallback}} instead of {{CredentialCallbak}} for checking the peer. Unfortunately, it is not easy for a callback handler to know when {{CredentialCallback}} is being used for the host identity versus the authenticating user identity. This needs to be solved ASAP so that we can have server mechanisms that present a host identity as well as acquiring a credential for user authentication.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1056) InstanceAlreadyExistsException in logs while starting embed-server after failure
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1056?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1056:
-------------------------------------
Fix Version/s: 2.0.2.Final
I'm scheduling this for 2.0.2.Final because it seems reasonable to think it will get done before WildFly 10.0.0.Final is done, so we can get into a 2.0.x release. 2.0.2.Final is planned for release tomorrow. If it doesn't make it into that, it's ok, it will just roll into 2.0.3.Final when I create that Fix Version.
> InstanceAlreadyExistsException in logs while starting embed-server after failure
> --------------------------------------------------------------------------------
>
> Key: WFCORE-1056
> URL: https://issues.jboss.org/browse/WFCORE-1056
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.CR6
> Reporter: Petr Kremensky
> Assignee: Ken Wills
> Fix For: 2.0.2.Final
>
>
> IAEE can be seen in the logs of embed server on the second startup if the first one fails.
> \\
> \\
> Starting the embed server with --emty-config using default configuration fails as expected.
> {noformat}
> [disconnected /] embed-server --std-out=echo --empty-config
> 10:12:35,251 INFO [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.4.4.Final
> 10:12:35,323 INFO [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.6.Final
> 10:12:35,384 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Core 2.0.0.CR7-SNAPSHOT (WildFly Core 2.0.0.CR7-SNAPSHOT) starting
> 10:12:35,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.as.server-controller: org.jboss.msc.service.StartException in service jboss.as.server-controller: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.IllegalStateException: WFLYCTL0389: Could not create an empty configuration at file /home/pkremens/devel/wildfly-core/dist/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone.xml as there is an existing non-empty configuration there
> at org.jboss.as.controller.persistence.ConfigurationFile.getBootFile(ConfigurationFile.java:242)
> at org.jboss.as.controller.persistence.BackupXmlConfigurationPersister.<init>(BackupXmlConfigurationPersister.java:70)
> at org.jboss.as.server.Bootstrap$Configuration$1.createConfigurationPersister(Bootstrap.java:192)
> at org.jboss.as.server.ServerService.start(ServerService.java:249)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on standalone server: WFLYSRV0141: Cannot start server: Operation failed: Failed to start service: WFLYCTL0389: Could not create an empty configuration at file /home/pkremens/devel/wildfly-core/dist/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone.xml as there is an existing non-empty configuration there
> {noformat}
> InstanceAlreadyExistsException can be seen in the logs during the boot of the embed server now.
> {noformat}
> [disconnected /] embed-server --std-out=echo
> 10:12:40,211 INFO [org.jboss.modules] (AeshProcess: 2) JBoss Modules version 1.4.4.Final
> 10:12:40,217 ERROR [org.jboss.msc] (AeshProcess: 2) MSC000010: Failed to register MBean with MBeanServer: javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=jboss-as
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:372)
> at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:208)
> at org.jboss.as.server.BootstrapImpl$ShutdownHook.access$100(BootstrapImpl.java:198)
> at org.jboss.as.server.BootstrapImpl.<init>(BootstrapImpl.java:62)
> at org.jboss.as.server.Bootstrap$Factory.newInstance(Bootstrap.java:256)
> at org.wildfly.core.embedded.EmbeddedStandaloneServerFactory$StandaloneServerImpl.start(EmbeddedStandaloneServerFactory.java:275)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.wildfly.core.embedded.EmbeddedServerReference.invokeOnServer(EmbeddedServerReference.java:85)
> at org.wildfly.core.embedded.EmbeddedServerReference.start(EmbeddedServerReference.java:56)
> at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:205)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:773)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:796)
> at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:410)
> at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 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)
> 10:12:40,227 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 2.0.0.CR7-SNAPSHOT (WildFly Core 2.0.0.CR7-SNAPSHOT) starting
> 10:12:40,678 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 2.0.0.CR7-SNAPSHOT (WildFly Core 2.0.0.CR7-SNAPSHOT) started in 465ms - Started 35 of 42 services (13 services are lazy, passive or on-demand)
> [standalone@embedded /]
> {noformat}
> Embed server functionality doesn't seem to be affected by the exception - is operable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months