[JBoss JIRA] (WFCORE-1671) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1671?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFCORE-1671:
----------------------------
Labels: downstream_dependency (was: )
> security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1671
> URL: https://issues.jboss.org/browse/WFCORE-1671
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Derek Horton
> Assignee: Lin Gao
> Labels: downstream_dependency
>
> security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following:
> <security-realm name="ManagementRealm">
> <authentication>
> <jaas name="jmx-console"/>
> </authentication>
> <authorization map-groups-to-roles="false">
> <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
> </authorization>
> </security-realm>
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="RealmUsersRoles" flag="required">
> <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/>
> <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> The following error is logged during the authentication attempt:
> 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347)
> at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174)
> at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175)
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161)
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6886) Drop ServiceLoader config for vault reader from security subsystem
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-6886?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-6886:
--------------------------
Labels: downstream_dependency (was: )
> Drop ServiceLoader config for vault reader from security subsystem
> ------------------------------------------------------------------
>
> Key: WFLY-6886
> URL: https://issues.jboss.org/browse/WFLY-6886
> Project: WildFly
> Issue Type: Task
> Components: Security
> Reporter: Lin Gao
> Assignee: Lin Gao
> Labels: downstream_dependency
>
> Having this META-INF/services file here means a caller could potentially try and load core's RuntimeVaultReader via this module instead of via core's server module. Which might work, or might partly work or... Since no code in full needs to load an AbstractVaultReader via this module I see no reason to support it.
> The vault resources in the security subsystem do not provide an AbstractVaultReader; they provide a Service (SecurityVault being the picketbox class.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6886) Drop ServiceLoader config for vault reader from security subsystem
by Lin Gao (JIRA)
Lin Gao created WFLY-6886:
-----------------------------
Summary: Drop ServiceLoader config for vault reader from security subsystem
Key: WFLY-6886
URL: https://issues.jboss.org/browse/WFLY-6886
Project: WildFly
Issue Type: Task
Components: Security
Reporter: Lin Gao
Assignee: Lin Gao
Having this META-INF/services file here means a caller could potentially try and load core's RuntimeVaultReader via this module instead of via core's server module. Which might work, or might partly work or... Since no code in full needs to load an AbstractVaultReader via this module I see no reason to support it.
The vault resources in the security subsystem do not provide an AbstractVaultReader; they provide a Service (SecurityVault being the picketbox class.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6885) Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
by Marcel Kolsteren (JIRA)
[ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.... ]
Marcel Kolsteren updated WFLY-6885:
-----------------------------------
Attachment: tx-timeout.zip
> Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6885
> URL: https://issues.jboss.org/browse/WFLY-6885
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Marcel Kolsteren
> Assignee: Jason Greene
> Attachments: tx-timeout.zip
>
>
> The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
> I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
> I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
> [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/o...]
> This happens (I verified by stepping through the code with the debugger):
> * The catch block of invokeInOurTx is entered.
> * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
> * The finally block of invokeInOurTx is entered.
> * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
> The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6885) Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
by Marcel Kolsteren (JIRA)
Marcel Kolsteren created WFLY-6885:
--------------------------------------
Summary: Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
Key: WFLY-6885
URL: https://issues.jboss.org/browse/WFLY-6885
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Reporter: Marcel Kolsteren
Assignee: Jason Greene
The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
[https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/o...]
This happens (I verified by stepping through the code with the debugger):
* The catch block of invokeInOurTx is entered.
* The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
* The finally block of invokeInOurTx is entered.
* The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin... ]
Aleksandar Kostadinov commented on WFCORE-433:
----------------------------------------------
[~brian.stansberry], storing diffs as CLI scripts sounds awesome as long as console can generate them and duplication of changes is removed. e.g. first set listen port to 445 and then change to 443. The first rule is then useless as it will be overridden by the second.
On the other hand journal-like diff also makes sense and being easier to implement is IMO good enough for most user stories.
> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
> Key: WFCORE-433
> URL: https://issues.jboss.org/browse/WFCORE-433
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Strachan
> Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-324) Resolve startup dependency between master hostController and slave hostControllers.
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-324?page=com.atlassian.jira.plugin... ]
Ken Wills updated WFCORE-324:
-----------------------------
Fix Version/s: 3.0.0.Alpha4
> Resolve startup dependency between master hostController and slave hostControllers.
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-324
> URL: https://issues.jboss.org/browse/WFCORE-324
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: karin k
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha4
>
>
> *Current situation:*
> * The slave hostController can be started using option --cached-dc
> Result: the slave hostContoller will be started given that a local copy of the domain.xml (exact name domain.cached-remote.xml
> ) is available (created by a startup using -backup and an available master hostController)
> The slave hostController will never register itself towards the master domain hostController (regardless of whether the master domain controller is running during startup or will be started afterwards)
> * The slave hostController can be started without any option
> If the master hostController is not running during startup of the slave, the startup of the slave will fail.
> * The slave hostController can be started with option -backup
> If the master hostController is not running during startup of the slave, the startup of the slave will fail.
> If the master hostController is running, the slave will store a copy of the domain.xml locally.
> A successful startup of the whole domain is only possible when the hostControllers are started in the correct sequence (master hostController must be available when slave host Controllers are trying to register). From my point of view a successful startup means that all hostControllers can start successfully and additionally it is possible to manage the slave hostController by means of the master hostController.
> *Requirement*
> To let a JBoss domain act and started in the correct way (meaning central management is possible) the following should be fullfilled
> * If the master hostController is not running, the slave should still be able to start and work with its local copy of the domain.xml
> * If the master hostController is started after the slave hostController, the slave host controller should still be able to start successfully but should in parallel recognize when the master hostController is finally available and register itself
> * There should be the possiblity to store a local copy of the domain master hostController in parallel with the approach of starting up when the master hostController is not running (in this case the master domain.xml cannot be stored locally but anyway startup is possible).
> (see also https://issues.jboss.org/browse/AS7-4281)
> Regards
> Karin
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months