[JBoss JIRA] (WFLY-8268) Obtain password from external source (CMD, EXT) doesn't work on Windows.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-8268:
----------------------------------
Summary: Obtain password from external source (CMD, EXT) doesn't work on Windows.
Key: WFLY-8268
URL: https://issues.jboss.org/browse/WFLY-8268
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Obtain password from external source (CMD, EXT) doesn't work on Windows.
Try to create new CS which obtains password from external source:
{code}
/subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir)
pass.bat file contains only this
{code}
echo %1
{code}
Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step:
Now you add new alias to CS -> JCEKS file is created
Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows.
In my opinion there is problem with back slashes in script path.
https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src...
Because when I add there back slashed to path then it works.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test
by Sunil kondkar (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plu... ]
Sunil kondkar resolved HAWKULARQE-32.
-------------------------------------
Resolution: Done
> Cassandra/Hawkular Schema Test
> ------------------------------
>
> Key: HAWKULARQE-32
> URL: https://issues.jboss.org/browse/HAWKULARQE-32
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Matt Mahoney
> Assignee: Sunil kondkar
>
> Test case request from Heiko (verbatim):
> Start C*,wait until up. Start metrics/h-services
> and once it starts schema creation (watch the logs), kill C*. Stop
> h-services. Start C* again and then h-services,it should continue Schema
> creation
> While I was talking about h-services here, this applies foremost to
> h-metrics (which is also used inside
> of h-services).
> Also I think Juca had a variation of this yesterday:
> deploy h-metrics + C* into Openshift and then scale h-metrics up and
> down at will.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test
by Sunil kondkar (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plu... ]
Sunil kondkar commented on HAWKULARQE-32:
-----------------------------------------
verified with docker start/stop cassandra and hawkular service containers manually. hawkular services continues schema creation if interrupted during initial install
Test Run:
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testr...
> Cassandra/Hawkular Schema Test
> ------------------------------
>
> Key: HAWKULARQE-32
> URL: https://issues.jboss.org/browse/HAWKULARQE-32
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Matt Mahoney
> Assignee: Sunil kondkar
>
> Test case request from Heiko (verbatim):
> Start C*,wait until up. Start metrics/h-services
> and once it starts schema creation (watch the logs), kill C*. Stop
> h-services. Start C* again and then h-services,it should continue Schema
> creation
> While I was talking about h-services here, this applies foremost to
> h-metrics (which is also used inside
> of h-services).
> Also I think Juca had a variation of this yesterday:
> deploy h-metrics + C* into Openshift and then scale h-metrics up and
> down at will.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-5319:
------------------------------------
Adding some more notes on this:
Note 1:
{quote}
I noticed that [1] TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest is now failing on the CI machine but not locally for me. I saved a copy of the test output [1], so that we could look at the possible causes.
1. Reaper thread throws a IllegalMonitorStateException from org.jboss.as.ejb3.tx.OwnableReentrantLock.unlock(). I'm not sure exactly why but I'm wondering if TransactionSynchronizationRegistry.getTransactionKey() returned null to StatefulSessionSynchronizationInterceptor.getLockOwner(), which causes the current "thread" to be used in the call to OwnableReentrantLock.unlock(). This happens at "21:06:34,782"
2. An exception is thrown in the application thread and the EJB container ends the transaction ("javax.ejb.EJBTransactionRolledbackException: Transaction rolled back" is thrown since the transaction is already rolled back).
3. Application thread fails unit test with "entity manager should not of been closed by the reaper thread" error. From the log, the entity manager is closed from the reaper thread at "21:06:34,782". The unit test failure is reported from the application thread at "21:06:34,800".
The test failure is clearly caused by (3) but that might reflect that the application thread was first disassociated from the active transaction and then the reaper thread ran the JPA container afterCompletion() synchronization callback (which is now legal but not expected IMO).
{quote}
Note 2, which refers back to note 1:
{quote}
I looked a little closer at (2) and the exception call stack points to the code at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) which is:
else if (txStatus == Status.STATUS_ROLLEDBACK) {
tm.rollback();
throw EjbLogger.ROOT_LOGGER.transactionAlreadyRolledBack(tx);
}
I don't really have any questions about (2), that is how the EJB container informs the application of the failure.
For (1), I am curious if TransactionSynchronizationRegistry.getTransactionKey() can be expected to return null when the reaper thread calls the afterCompletion sync callback?
For (3), it seems likely that the application thread was first disassociated from the transaction and then the JPA afterCompletion was invoked, which (properly) closed the container managed entity manager. If this is what happened, then TxTimeoutTestCase needs to check for different conditions to detect (potential) concurrency failure.
{quote}
> fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5319
> URL: https://issues.jboss.org/browse/WFLY-5319
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8267) Unable to undefine credential-reference
by Tomas Hofman (JIRA)
Tomas Hofman created WFLY-8267:
----------------------------------
Summary: Unable to undefine credential-reference
Key: WFLY-8267
URL: https://issues.jboss.org/browse/WFLY-8267
Project: WildFly
Issue Type: Bug
Components: JMS, Security
Reporter: Tomas Hofman
Assignee: Tomas Hofman
A bridge is added and a credential-reference is set.
However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value.
Also neither credential-reference and password are required=true, so they may be undefined.
{code}
/profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ)
/profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1})
/profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."},
"rolled-back" => true
}
{code}
The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference
{code}
/profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1)
/profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."},
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.... ]
Tomas Hofman commented on WFLY-8238:
------------------------------------
This is a bug in messaging subsystem - {{AlternativeAttributeCheckHandler}} doesn't allow to undefine attributes where alternatives are set, if the alternatives are undefined. It should take into account whether the attribute is required or not, which it doesn't and treats them always as required.
When this is changed it will affect number of other attributes across the subsystem, and for some the "required" behaviour may be desirable. I didn't find any attributes that would be marked as required and had alternatives set too, which is probably a mistake.
> Unable to undefine credential-reference
> ---------------------------------------
>
> Key: WFLY-8238
> URL: https://issues.jboss.org/browse/WFLY-8238
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Security
> Reporter: Claudio Miranda
> Assignee: Tomas Hofman
>
> A bridge is added and a credential-reference is set.
> However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value.
> Also neither credential-reference and password are required=true, so they may be undefined.
> {code}
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ)
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1})
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."},
> "rolled-back" => true
> }
> {code}
> The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference
> {code}
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1)
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."},
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test
by Sunil kondkar (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plu... ]
Sunil kondkar commented on HAWKULARQE-32:
-----------------------------------------
Tested manually as below:
1) create/start cassandra version 3.10
ccm create hawkular -v 3.10 -n 1
ccm updateconf "start_rpc: true"
ccm start
2) Start hawkular service version 33
./standalone.sh -Dhawkular.rest.user=jdoe -Dhawkular.rest.password=password -Dhawkular.agent.enabled=true
3) Stopped cassandra with 'ccm stop' when I see below in logs
08:03:14,852 INFO [org.hawkular.metrics.schema.SchemaService] (metricsservice-lifecycle-thread) Creating table metrics_tags_idx
08:03:16,038 INFO [org.hawkular.metrics.schema.SchemaService] (metricsservice-lifecycle-thread) Creating table metrics_idx
4) Stopped hawkular services
5) Started cassandra with ccm start
6) Verified hawkular service continues schema creation.
> Cassandra/Hawkular Schema Test
> ------------------------------
>
> Key: HAWKULARQE-32
> URL: https://issues.jboss.org/browse/HAWKULARQE-32
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Matt Mahoney
> Assignee: Sunil kondkar
>
> Test case request from Heiko (verbatim):
> Start C*,wait until up. Start metrics/h-services
> and once it starts schema creation (watch the logs), kill C*. Stop
> h-services. Start C* again and then h-services,it should continue Schema
> creation
> While I was talking about h-services here, this applies foremost to
> h-metrics (which is also used inside
> of h-services).
> Also I think Juca had a variation of this yesterday:
> deploy h-metrics + C* into Openshift and then scale h-metrics up and
> down at will.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-978) MechanismInformationCallback blocks certificate based authn (Undertow with Elytron)
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/ELY-978?page=com.atlassian.jira.plugin.sy... ]
Ondrej Kotek closed ELY-978.
----------------------------
Resolution: Won't Fix
Not a bug. {{CLIENT_CERT}} mechanism name has to used in {{http-authentication-factory}} instead of {{CLIENT-CERT}}. [~zrhoads], could you fix the documentation [1] please?
> MechanismInformationCallback blocks certificate based authn (Undertow with Elytron)
> -----------------------------------------------------------------------------------
>
> Key: ELY-978
> URL: https://issues.jboss.org/browse/ELY-978
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.1.0.Beta26
> Reporter: Ondrej Kotek
> Priority: Blocker
> Labels: authentication, eap71_alpha, http, ssl
> Attachments: deployment.war, standalone.xml
>
>
> It is not possible to set up authentication based on certificates. Following the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything works as expected until a client with {{client}} certificate tries to access protected resource that should be accessible. Such resource returns 403 Forbidden instead of 200 OK. Trace log:
> {noformat}
> 13:31:15,565 TRACE [org.wildfly.security] (default task-33) Evidence verification: evidence = org.wildfly.security.evidence.X509PeerCertificateChainEvidence@42d7e114 evidencePrincipal = CN=client
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) X500 principal [CN=client] decoded as name [client] (attribute values: [client])
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post realm rewritten: [client], realm rewritten: [client]
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) X500 principal [CN=client] decoded as name [client] (attribute values: [client])
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Evidence verification succeed for alias [client]
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [Guest, Admin]
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Authorizing principal client.
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Authorizing against the following attributes: [] => []
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Permission mapping: identity [client] with roles [Guest, Admin] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Authorization succeed
> 13:31:15,566 TRACE [org.wildfly.security] (default task-33) Authentication succeed for principal [CN=client]
> 13:31:15,573 TRACE [org.wildfly.security] (default task-34) Handling MechanismInformationCallback
> 13:31:15,574 TRACE [org.wildfly.security] (default task-34) java.lang.IllegalStateException: ELY01119: Unable to resolve MechanismConfiguration for mechanismType='HTTP', mechanismName='CLIENT_CERT', hostName='localhost', protocol='https'.
> {noformat}
> The last message comes from {{ServerAuthenticationContext}} [3].
> [1] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [2] https://docs.jboss.org/author/display/WFLY/Using+the+Elytron+Subsystem#Us...
> [3] https://github.com/wildfly-security/wildfly-elytron/blob/6e4dad322ab04215...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months