[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-2746:
-----------------------------------
[~olukas] I've encountered a couple of those converting tests. So far using @BeforeClass, @AfterClass, @Before & @After have been able to handle the setup and running tests OK. The problematic bit is, as you suggest your step 3 (assuming the same tests are run in 4). Do you have an existing example, or something planned?
I'm not sure we'd have a way of doing what you're describing easily, but pinging [~jamezp] in case he can suggest something with the WildflyTestRunner.
> Move elytron management security tests from full to core
> --------------------------------------------------------
>
> Key: WFCORE-2746
> URL: https://issues.jboss.org/browse/WFCORE-2746
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management, Security, Test Suite
> Reporter: Brian Stansberry
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> org.jboss.as.test.integration.security.credentialreference [2]
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1126) WildFly Elytron Tool, Vault command summary contains MASKed password without iteration and salt when is used MASKed password for access to VAULT.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-1126?page=com.atlassian.jira.plugin.s... ]
Hynek Švábek updated ELY-1126:
------------------------------
Summary: WildFly Elytron Tool, Vault command summary contains MASKed password without iteration and salt when is used MASKed password for access to VAULT. (was: WildFly Elytron Tool, Vault command summary contains MASKed password without --iteration and --salt when is used MASKed password for access to VAULT.)
> WildFly Elytron Tool, Vault command summary contains MASKed password without iteration and salt when is used MASKed password for access to VAULT.
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1126
> URL: https://issues.jboss.org/browse/ELY-1126
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> Vault command summary contains MASKed password without --iteration and --salt when is used MASKed password for access to VAULT.
> MASKed password must contain SALT and ITERATION as is expected:
> *credential-reference=\{clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"\}*
> FYI: plain text password is "secretsecret".
> *How to reproduce*
> Download all attachments to same location as *wildfly-elytron-tool.jar* and run this command:
> {code}
> [hsvabek@dhcp-10-40-5-100 003]$ java -jar wildfly-elytron-tool.jar vault --enc-dir . --keystore server.store --keystore-password MASK-2hKo56F1a3jYGnJwhPmiF5 --salt 12345678 --iteration 34 --location converted001.store --alias jboss --summary
> Vault (enc-dir=".";keystore="server.store") converted to credential store "converted001.store"
> Vault Conversion summary:
> --------------------------------------
> Vault Conversion Successful
> CLI command to add new credential store:
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="converted001.store",implementation-properties={},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5"})
> {code}
> Credential reference contains MASKed password without salt and iteration (credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5"})
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1126) WildFly Elytron Tool, Vault command summary contains MASKed password without --iteration and --salt when is used MASKed password for access to VAULT.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1126?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1126:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> WildFly Elytron Tool, Vault command summary contains MASKed password without --iteration and --salt when is used MASKed password for access to VAULT.
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1126
> URL: https://issues.jboss.org/browse/ELY-1126
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> Vault command summary contains MASKed password without --iteration and --salt when is used MASKed password for access to VAULT.
> MASKed password must contain SALT and ITERATION as is expected:
> *credential-reference=\{clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5;12345678;34"\}*
> FYI: plain text password is "secretsecret".
> *How to reproduce*
> Download all attachments to same location as *wildfly-elytron-tool.jar* and run this command:
> {code}
> [hsvabek@dhcp-10-40-5-100 003]$ java -jar wildfly-elytron-tool.jar vault --enc-dir . --keystore server.store --keystore-password MASK-2hKo56F1a3jYGnJwhPmiF5 --salt 12345678 --iteration 34 --location converted001.store --alias jboss --summary
> Vault (enc-dir=".";keystore="server.store") converted to credential store "converted001.store"
> Vault Conversion summary:
> --------------------------------------
> Vault Conversion Successful
> CLI command to add new credential store:
> /subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="converted001.store",implementation-properties={},credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5"})
> {code}
> Credential reference contains MASKed password without salt and iteration (credential-reference={clear-text="MASK-2hKo56F1a3jYGnJwhPmiF5"})
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1547) Add tests to confirm that singleton lists can be treated as the element itself in filter results
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1547?page=com.atlassian.jira.plugi... ]
Matteo Mortari reassigned DROOLS-1547:
--------------------------------------
Assignee: Matteo Mortari (was: Edson Tirelli)
> Add tests to confirm that singleton lists can be treated as the element itself in filter results
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1547
> URL: https://issues.jboss.org/browse/DROOLS-1547
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Affects Versions: 7.0.0.CR3
> Reporter: Edson Tirelli
> Assignee: Matteo Mortari
> Fix For: 7.1.0.Final
>
> Attachments: Ex_6_1.dmn
>
>
> The specification has a provision that singleton lists should be treated as the element itself in some cases, like filter results. I.e., in some cases, {{[a] = a}}.
> This is not completely consistent, but we need to handle it for some cases, like filter results. In other words, the following assignment should work fine, assuming {{a flight}} is a flight variable and {{flight list}} is a list of flights, and the filter returns a single result.
> {code}
> {
> a flight : flight list[ number = "AC 531" ]
> }
> {code}
> We need to add tests to make sure it is working like that and fix it in case it is not.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1558) DMN case where list of single element shall be considered a singleton value
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1558?page=com.atlassian.jira.plugi... ]
Matteo Mortari resolved DROOLS-1558.
------------------------------------
Resolution: Duplicate Issue
This was actually duplicating [DROOLS-1547].
> DMN case where list of single element shall be considered a singleton value
> ---------------------------------------------------------------------------
>
> Key: DROOLS-1558
> URL: https://issues.jboss.org/browse/DROOLS-1558
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.0.0.CR3
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Fix For: 7.1.0.Final
>
> Attachments: Ex_6_1.dmn
>
>
> In the attached model decision "Positions of Los Angeles teams" is wrong:
> {code:java}
> index of(NBA Pacific[city="Los Angeles"])
> {code}
> As the "index of" function expects 2 parameters.
> It could be rewritten as:
> {code:java}
> index of(NBA Pacific.city, "Los Angeles")
> {code}
> which would work, but there is an expectations it should also work with:
> {code:java}
> index of( NBA Pacific, NBA Pacific[city="Los Angeles"])
> {code}
> under the assumption there is only 1 team located in LA, so {{NBA Pacific[city="Los Angeles"]}} is a List of only 1 element, the team located in LA.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1547) Add tests to confirm that singleton lists can be treated as the element itself in filter results
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1547?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1547:
-----------------------------------
Attachment: Ex_6_1.dmn
> Add tests to confirm that singleton lists can be treated as the element itself in filter results
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1547
> URL: https://issues.jboss.org/browse/DROOLS-1547
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Affects Versions: 7.0.0.CR3
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 7.1.0.Final
>
> Attachments: Ex_6_1.dmn
>
>
> The specification has a provision that singleton lists should be treated as the element itself in some cases, like filter results. I.e., in some cases, {{[a] = a}}.
> This is not completely consistent, but we need to handle it for some cases, like filter results. In other words, the following assignment should work fine, assuming {{a flight}} is a flight variable and {{flight list}} is a list of flights, and the filter returns a single result.
> {code}
> {
> a flight : flight list[ number = "AC 531" ]
> }
> {code}
> We need to add tests to make sure it is working like that and fix it in case it is not.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1547) Add tests to confirm that singleton lists can be treated as the element itself in filter results
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1547?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1547:
----------------------------------------
In addition to filter result returning, also parameter function call should be considered.
In the attached model decision "Positions of Los Angeles teams" is wrong:
{code:java}
index of(NBA Pacific[city="Los Angeles"])
{code}
As the "index of" function expects 2 parameters.
It could be rewritten as:
{code:java}
index of(NBA Pacific.city, "Los Angeles")
{code}
which would work, but there is an expectations it should also work with:
{code:java}
index of( NBA Pacific, NBA Pacific[city="Los Angeles"])
{code}
under the assumption there is only 1 team located in LA, so NBA Pacific[city="Los Angeles"] is a List of only 1 element, the team located in LA.
> Add tests to confirm that singleton lists can be treated as the element itself in filter results
> ------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1547
> URL: https://issues.jboss.org/browse/DROOLS-1547
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Affects Versions: 7.0.0.CR3
> Reporter: Edson Tirelli
> Assignee: Edson Tirelli
> Fix For: 7.1.0.Final
>
> Attachments: Ex_6_1.dmn
>
>
> The specification has a provision that singleton lists should be treated as the element itself in some cases, like filter results. I.e., in some cases, {{[a] = a}}.
> This is not completely consistent, but we need to handle it for some cases, like filter results. In other words, the following assignment should work fine, assuming {{a flight}} is a flight variable and {{flight list}} is a list of flights, and the filter returns a single result.
> {code}
> {
> a flight : flight list[ number = "AC 531" ]
> }
> {code}
> We need to add tests to make sure it is working like that and fix it in case it is not.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2670) list-add doesn't work for nested list of child attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2670?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2670:
------------------------------------------
It will be done as soon as someone reviews the PR so I can merge it. I've pinged the world; we'll see what happens.
> list-add doesn't work for nested list of child attribute
> --------------------------------------------------------
>
> Key: WFCORE-2670
> URL: https://issues.jboss.org/browse/WFCORE-2670
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
> Priority: Critical
>
> The list-add doesn't work for a child of an attribute as in the example below
> Add a dir-context first
> {code}
> /profile=full/subsystem=elytron/dir-context=dir2:add(url="ldap://test")
> {code}
> Add a ldap-realm
> {code}
> /profile=full/subsystem=elytron/ldap-realm=foobar2:add(dir-context=dir2,identity-mapping={rdn-identifier=test})
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }}}}}}
> }
> {code}
> This is the command to add the item to the list
> {code}
> /profile=full/subsystem=elytron/ldap-realm=foobar2:list-add(name=identity-mapping.new-identity-attributes,value={name=key2,value=["val1","val2"]})
> {
> "outcome" => "failed",
> "result" => undefined,
> "server-groups" => undefined,
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-1680) RDMA based transport
by Ben Cotton (JIRA)
[ https://issues.jboss.org/browse/JGRP-1680?page=com.atlassian.jira.plugin.... ]
Ben Cotton commented on JGRP-1680:
----------------------------------
Awesome. Exactly! Java 7 introduced SDP ...
Bela, Carry on.
> RDMA based transport
> --------------------
>
> Key: JGRP-1680
> URL: https://issues.jboss.org/browse/JGRP-1680
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.x
>
>
> Investigate whether an RDMA based transport makes sense.
> Advantages:
> * Speed, low latency (TCP/IP is bypassed entirely)
> * Low CPU usage
> Disadvantages:
> * JNI/C code
> ** Such a transport implementation would have to live outside of the JGroups repo
> ** Maintainability nightmare: the C code would also have to be ported to various OSes
> *** Investigate Java based libs (IBM's jVerbs) and C based libs (Apache Portable Runtime?)
> * High memory use, growing with cluster size: similarly to TCP, a 'group multicast' would involve N-1 sends. RDMA requires a Queue Pair (QP) for each destination. Each QP requires pinned memory (receive and send buffer), so each node would have to reserve (pin) N-1 memory buffers [1]
> ** OTOH, we may not use many group multicasts, e.g. with Infinispan's partial replication (DIST mode)
> * High cost of RDMA adapters, NICs and wiring: only a very small fraction of users would run such a transport.
> [1] http://www.hpcwire.com/hpcwire/2006-08-18/a_critique_of_rdma-1.html
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months