[JBoss JIRA] (WFLY-9561) HttpServletRequest.login(username, password) not creating HttpSession if it doesn't already exist. (Elytron)
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-9561?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-9561.
------------------------------------
Resolution: Done
> HttpServletRequest.login(username, password) not creating HttpSession if it doesn't already exist. (Elytron)
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9561
> URL: https://issues.jboss.org/browse/WFLY-9561
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Stanislav Grushevskiy
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 12.0.0.Final
>
> Attachments: test.zip
>
>
> If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID".
> @Path("login")
> public class LoginService {
> @Context
> private HttpServletRequest request;
> @POST
> public void login(LoginForm form) throws ServletException {
> request.login(form.getLogin(), form.getPassword());
> }
> }
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>application-security-domain</security-domain>
> </jboss-web>
> If I add manual interaction with Session in login method, "JSESSIONID" is set.
> OR
> If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set.
> "JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used.
> Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly".
> Run "mvn wildfly:deploy".
> Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth".
> In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below (<!-- comment the row below to use default ApplicationRealm from old security system, not elytron -->) to use old "ApplicationRealm".
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-3002) (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3002?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3002:
------------------------------------------
[~fjuma] May be worth us thinking about this with other SSL/TLS changes? Should a client be able to force the use of SSL/TLS?
> (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3002
> URL: https://issues.jboss.org/browse/WFCORE-3002
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management, Security
> Reporter: Josef Cacek
> Priority: Major
>
> The ModelControllerClient is not able to force using SSL/TLS connection with management native interface.
> *Usecase:* As an administrator I want to be sure that a ModelControllerClient connection to management native-interface goes through a secure connection. (I.e. Client connection is only established when the server uses SSL/TLS).
> Setting a blocker priority, as this can lead to security leaks, when a client assumes the secure management connection is used and the opposite is true and such a connection can be easily eavesdropped.
> My first try was to use ModelControllerClient configuration to set SSL context:
> {code:java}
> new ModelControllerClientConfiguration.Builder().setSslContext(sslFactory.create())
> .setProtocol("remote");
> {code}
> Nevertheless such a configuration doesn't force using SSL and if the server doesn't have SSL context configured, then the created connection is a plain remoting one.
> Next try was to configure the SSL context in Elytron's {{AuthenticationContext}}:
> {code:java}
> AuthenticationContext.withSsl(MatchRule.ALL, sslContext)
> {code}
> The result was the same (i.e. plain connection was used). [~dlofthouse] commented on this on Hipchat:
> {quote}
> In terms of Elytron configuration generally the config provided is there so it can be used if it is needed rather than it forming some form of mandatory policy. So in this case I would expect you would drive that more with the protocol you specify e.g. remote+tls or remote+https
> {quote}
> Based on the comment I've used "remote+tls" protocol on the client:
> {code:java}
> ModelControllerClientConfiguration.Builder().setProtocol("remote+tls")
> {code}
> but in this case the connection fails even if the server has the sslContext configured:
> {code:xml}
> <management-interfaces>
> <native-interface sasl-authentication-factory="test-sasl-authn-factory" ssl-context="elytron-ssl-context">
> <socket-binding native="testbinding"/>
> </native-interface>
> ...
> </management-interfaces>
> {code}
> The failure:
> {noformat}
> java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ... [cropped]
> Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> ... 144 more
> Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) [jsse.jar:1.8.0_131]
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) [rt.jar:1.8.0_131]
> at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.unwrap(AbstractDelegatingSSLEngine.java:56) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.engineUnwrap(JsseSslConduitEngine.java:688) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:172) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:167) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioHandle$1.run(NioHandle.java:50) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:472) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:509) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> {noformat}
> Am I missing some piece of configuration here?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-10348) Picketlink federation XML writer should not rely on the ordering in the ModelNode
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-10348?page=com.atlassian.jira.plugin... ]
Darran Lofthouse resolved WFLY-10348.
-------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Fix
Marking as 'Won't Fix' as this subsystem is now deprecated.
> Picketlink federation XML writer should not rely on the ordering in the ModelNode
> ---------------------------------------------------------------------------------
>
> Key: WFLY-10348
> URL: https://issues.jboss.org/browse/WFLY-10348
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Alexey Loubyansky
> Assignee: Darran Lofthouse
> Priority: Major
>
> AFAICS, FederationSubsystemWriter is relying on the ordering of the children of the root ModelNode when persisting the subsystem configuration. If one was to create a configuration using management operations from scratch, the operations would have to be ordered according to the order of the corresponding elements defined in the XSD schema. Which is not very practical and increases the chance of getting errors that could be avoided by making the writer persist the elements in the valid order.
> E.g. in the current implementation if a management operation configuring key-store appeared after the one(s) configuring service-providers the resulting subsystem XML would be invalid according to the XSD.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-2423) Elytron resources runtime updates without reload
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-2423?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2423.
--------------------------------------
Resolution: Rejected
> Elytron resources runtime updates without reload
> ------------------------------------------------
>
> Key: WFCORE-2423
> URL: https://issues.jboss.org/browse/WFCORE-2423
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta7
> Reporter: Martin Choma
> Assignee: Dmitrii Tikhomirov
> Priority: Major
>
> When updating elytron resources, server ends up in {{reload-required}} state. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> Make it possible for all (most - some may be impossible) resources to support runtime updates.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-3747) Enhance credential-store description related to location and type attributes
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-3747?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-3747:
----------------------------------------
Assignee: Darran Lofthouse
> Enhance credential-store description related to location and type attributes
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3747
> URL: https://issues.jboss.org/browse/WFCORE-3747
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Darran Lofthouse
> Priority: Major
>
> The description for "location" and "type" for credential-store resource is displayed below.
> Following discussion of WFCORE-3458, the "location" attribute is required only when the "type" is file based, but the description doesn't says that, the description may be improved to reflect this behavior and list the possible file based types.
> When the user doesn't set the "type" attribute it defaults to "JCEKS", but there is no "default" value on resource description for "type" attribute.
> {code}
> "location" => {
> "type" => STRING,
> "description" => "File name of credential store storage.",
> "attribute-group" => "implementation",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> "type" => {
> "type" => STRING,
> "description" => "The credential store type, e.g. KeyStoreCredentialStore.",
> "attribute-group" => "implementation",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-8431.
------------------------------------
Resolution: Won't Fix
Marking as 'Won't Fix' as this is in relation to PicketBox which is now deprecated.
> Race conditions in JASPIC registration code
> -------------------------------------------
>
> Key: WFLY-8431
> URL: https://issues.jboss.org/browse/WFLY-8431
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Centos 7 x86_64, with the included Java 8 environment
> Reporter: István Tóth
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: GetFactoryTestCase.java
>
>
> javax.security.auth.message.config.AuthConfigFactory and
> org.jboss.security.auth.message.config.JBossAuthConfigFactory
> have race conditions.
> 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic.
> I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized)
> 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe.
> Nearly all methods of this class manipulate these, without any synchronization.
> In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty.
> The methods that modify the maps should also be made synchronized, or rewritten to use the
> atomic ConcurrentHashMaps operations.
> A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-9212) Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object, Subject)
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-9212?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-9212.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Fix
Marking as 'Won't Fix' as in relation to PicketBox which is now deprecated.
> Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object,Subject)
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9212
> URL: https://issues.jboss.org/browse/WFLY-9212
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Scott Stark
> Assignee: Darran Lofthouse
> Priority: Major
>
> I have a custom JWT based auth method and JAAS login module that I'm testing with swarm which is using WFLY 10.1.0.Final. I am not able to install a custom Principal instance for retrieval via the JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() because of how the JAASIdentityManagerImpl#verifyCredential(final AccountImpl account, final Object credential) method populates the SecurityContext.SecurityContextUtil SubjectInfo.
> The following line:
> https://github.com/wildfly/wildfly/blob/c3332cec0c9bc5dc57899c2ae7ba26dd0...
> sc.getUtil().createSubjectInfo(incomingPrincipal, credential, subject);
> Is using the incomingPrincipal, which is derived from the simple AccountImpl wrapping of the incoming String id. In my call path, this is the user id before any authentication has happened as there is no originalPrincipal value on the AccountImpl, so it is not the best representation of the authenticated caller, and the wrapping Principal instance does not exist amongst the authenticated Subject#getPrincipals().
> I see this is due to a CallerPrincipal issue:
> https://issues.jboss.org/browse/WFLY-3626
> but one needs to be able to control what form of the authenticated userPrincipal that is returned by the user facing container getUserPrincipal() type of API calls.
> See the getPrincipalClass() unit test in this repo for an example of what is being tested:
> https://github.com/MicroProfileJWT/microprofile-jwt-auth-wfswarm/blob/f39...
> I can work around this by overriding the SubjectInfo by immediately after the auth mechanism has called the SecurityContext#authenticationComplete(...) using:
> // Workaround authenticated JWTPrincipal not being installed as user principal
> org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
> Subject subject = jbSC.getUtil().getSubject();
> jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
> I have tried wrapping the Account passed into SecurityContext#authenticationComplete(...) and that has not worked so far, but I'll look again to see if there is something else I can override to achieve the desired behavior.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-10042) Elytron tests fail intermittently
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-10042?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFLY-10042:
------------------------------------
Component/s: JMX
> Elytron tests fail intermittently
> ---------------------------------
>
> Key: WFLY-10042
> URL: https://issues.jboss.org/browse/WFLY-10042
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Security
> Reporter: Stuart Douglas
> Priority: Major
>
> The JMX MBean server service does not have correct dependencies set on the security domain, and as a result unregistering the Arquillian MBean can fail on reload.
> If this happen all subsequent tests will fail as the Arquillian service will not start correctly.
> An example run is at: https://ci.wildfly.org/viewLog.html?buildId=89151&buildTypeId=WFPR&tab=bu...
> {code}
> 2018-02-12 09:31:55,112 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 31) WFLYUT0022: Unregistered web context: '/chained-principal-transformer-transform-transformed' from server 'default-server'
> 2018-02-12 09:31:55,118 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment chained-principal-transformer-transform-transformed.war (runtime-name: chained-principal-transformer-transform-transformed.war) in 6ms
> 2018-02-12 09:31:55,129 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /store/work/tc-work/9ccd5e119c4a65d0/testsuite/integration/elytron/target/wildfly/standalone/data/content/7b/30341090e956f73f2066f8e357380151a337e8/content
> 2018-02-12 09:31:55,129 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "chained-principal-transformer-transform-transformed.war" (runtime-name: "chained-principal-transformer-transform-transformed.war")
> 2018-02-12 09:31:55,563 ERROR [org.jboss.as.arquillian] (MSC service thread 1-8) Cannot stop Arquillian Test Runner: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:60)
> at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1180)
> at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
> at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.isRegistered(MBeanServerAuditLogRecordFormatter.java:176)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.isRegistered(PluggableMBeanServerImpl.java:784)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.unregisterMBean(JMXTestRunner.java:109)
> at org.jboss.as.arquillian.service.ArquillianService.stop(ArquillianService.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1767)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1740)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1527)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1360)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months