March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2505) Key store exported from legacy security domain does not work Elytron filtering-key-store

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2505?page=com.atlassian.jira.plugi... ] Ondrej Kotek updated WFCORE-2505: --------------------------------- Steps to Reproduce: # {{/subsystem=security/security-domain=cert-roles-domain:add}} # {noformat}/subsystem=security/security-domain=cert-roles-domain/jsse=classic:add(truststore={password=secret, url="/path/to/server.truststore.jks"}, keystore={password=secret, url="/path/to/server.keystore.jks"}, client-auth=true){noformat} # {{/subsystem=security/elytron-key-store=eks:add(legacy-jsse-config=cert-roles-domain)}} # {{/subsystem=elytron/filtering-key-store=fks:add(alias-filter=ALL,key-store=eks)}} was: # {{/subsystem=security/security-domain=cert-roles-domain:add}} # {{/subsystem=security/security-domain=cert-roles-domain/jsse=classic:add(truststore={password=secret, url="/path/to/server.truststore.jks"}, keystore={password=secret, url="/path/to/server.keystore.jks"}, client-auth=true)}} # {{/subsystem=security/elytron-key-store=eks:add(legacy-jsse-config=cert-roles-domain)}} # {{/subsystem=elytron/filtering-key-store=fks:add(alias-filter=ALL,key-store=eks)}} > Key store exported from legacy security domain does not work Elytron filtering-key-store > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2505 > URL: https://issues.jboss.org/browse/WFCORE-2505 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta6 > Reporter: Ondrej Kotek > Priority: Critical > > It is not possible to use a key store exported from legacy security domain (i.e. {{elytron-key-store}}) in Elytron {{filtering-key-store}}. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService > Caused by: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"] > }, > "rolled-back" => true > } > {noformat} > The exported key store is announced as {{org.wildfly.security.key-store}} capability. Hence it is expected to work wherever the capability is requested. > The same applies to {{elytron-trust-store}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2505) Key store exported from legacy security domain does not work Elytron filtering-key-store

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2505?page=com.atlassian.jira.plugi... ] Ondrej Kotek moved JBEAP-9398 to WFCORE-2505: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2505 (was: JBEAP-9398) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta6 (was: 7.1.0.DR13) > Key store exported from legacy security domain does not work Elytron filtering-key-store > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2505 > URL: https://issues.jboss.org/browse/WFCORE-2505 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta6 > Reporter: Ondrej Kotek > Priority: Critical > > It is not possible to use a key store exported from legacy security domain (i.e. {{elytron-key-store}}) in Elytron {{filtering-key-store}}. It results in: > {noformat} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService > Caused by: java.lang.ClassCastException: org.jboss.as.security.elytron.BasicService cannot be cast to org.wildfly.extension.elytron.ModifiableKeyStoreService"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"] > }, > "rolled-back" => true > } > {noformat} > The exported key store is announced as {{org.wildfly.security.key-store}} capability. Hence it is expected to work wherever the capability is requested. > The same applies to {{elytron-trust-store}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2504) Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2504?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-2504: ------------------------------- Git Pull Request: https://github.com/wildfly-security/elytron-subsystem/pull/402, https://github.com/wildfly-security-incubator/wildfly-core/pull/52 (was: https://github.com/wildfly-security/elytron-subsystem/pull/402, https://github.com/wildfly-security/elytron-subsystem/pull/442) > Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-2504 > URL: https://issues.jboss.org/browse/WFCORE-2504 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The default Elytron configuration in profiles doesn't configure {{JBOSS-LOCAL-USER}} SASL mechanism for ApplicationRealm. If a client (e.g JMS/naming) uses local authentication in legacy security, it will not work after switching to Elytron based security. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2504) Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2504?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFLY-7996 to WFCORE-2504: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2504 (was: WFLY-7996) Component/s: Security (was: Security) Fix Version/s: 3.0.0.Beta8 (was: 11.0.0.Alpha1) > Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-2504 > URL: https://issues.jboss.org/browse/WFCORE-2504 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > Fix For: 3.0.0.Beta8 > > > The default Elytron configuration in profiles doesn't configure {{JBOSS-LOCAL-USER}} SASL mechanism for ApplicationRealm. If a client (e.g JMS/naming) uses local authentication in legacy security, it will not work after switching to Elytron based security. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet commented on WFCORE-2360: ------------------------------------------- Removing the server will trigger a model synchronization on the slave which happens before the RUNTIME phase during which the server status is checked, so we fail before the verify-server-status operation. > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain@localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain@localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-988) Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-988?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas commented on ELY-988: ---------------------------------- As part of fix please remove related ignores in [1]. It can be done as part of PR which will fix this issue. [1] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/test/... > Methods 'replacing' and 'replacingSslContext' in AuthenticationContext work incorrectly > --------------------------------------------------------------------------------------- > > Key: ELY-988 > URL: https://issues.jboss.org/browse/ELY-988 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > According to their javadoc, these methods should replace the rule and configuration (or SSL context) at the given index with the given rule and configuration. > In case when AuthenticationContext is defined with RuleNode - RuleA, RuleB, RuleC and RuleNode {{replacing}} method is called for index1 and RuleD, then: > * correct behavior should be - new AuthenticationContext with rule ordered - RuleA, RuleD, RuleC is created > * current behavior is - new AuthenticationContext with rule ordered - RuleD, RuleD, RuleB RuleC is created > Behavior of these methods is correct only in case when they are called with index 0. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-986) Method equals for MatchRule throws java.lang.IllegalStateException

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-986?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas edited comment on ELY-986 at 3/8/17 6:26 AM: ---------------------------------------------------------- Please uncomment following line [1] when this issue will be fixed (it can be done as part of PR which will fix this issue). [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb6d2652442236a0... was (Author: olukas): Please uncomment following line [1] when this issue will be fixed. [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb6d2652442236a0... > Method equals for MatchRule throws java.lang.IllegalStateException > ------------------------------------------------------------------ > > Key: ELY-986 > URL: https://issues.jboss.org/browse/ELY-986 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In case when method {{equals(MatchRule other)}} is called on {{org.wildfly.security.auth.client.MatchRule}} then it finishes with java.lang.IllegalStateException with following stack trace, for calling {{MatchRule.ALL.equals(MatchRule.ALL);}}: > {code} > java.lang.IllegalStateException > at org.wildfly.security.auth.client.MatchRule$1.getMatchUser(MatchRule.java:102) > at org.wildfly.security.auth.client.MatchRule.getMatchUser(MatchRule.java:500) > at org.wildfly.security.auth.client.MatchNoUserRule.halfEqual(MatchNoUserRule.java:46) > at org.wildfly.security.auth.client.MatchRule.equals(MatchRule.java:157) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-986) Method equals for MatchRule throws java.lang.IllegalStateException

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-986?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas commented on ELY-986: ---------------------------------- Please uncomment following line [1] when this issue will be fixed. [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb6d2652442236a0... > Method equals for MatchRule throws java.lang.IllegalStateException > ------------------------------------------------------------------ > > Key: ELY-986 > URL: https://issues.jboss.org/browse/ELY-986 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > In case when method {{equals(MatchRule other)}} is called on {{org.wildfly.security.auth.client.MatchRule}} then it finishes with java.lang.IllegalStateException with following stack trace, for calling {{MatchRule.ALL.equals(MatchRule.ALL);}}: > {code} > java.lang.IllegalStateException > at org.wildfly.security.auth.client.MatchRule$1.getMatchUser(MatchRule.java:102) > at org.wildfly.security.auth.client.MatchRule.getMatchUser(MatchRule.java:500) > at org.wildfly.security.auth.client.MatchNoUserRule.halfEqual(MatchNoUserRule.java:46) > at org.wildfly.security.auth.client.MatchRule.equals(MatchRule.java:157) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1470) Match.getObjects() should also include accumulate's objects

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1470?page=com.atlassian.jira.plugi... ] Geoffrey De Smet edited comment on DROOLS-1470 at 3/8/17 6:22 AM: ------------------------------------------------------------------ Pr with reproducing unit test submitted. https://github.com/droolsjbpm/drools/pull/1131/files#diff-29e145e93ea28f5... was (Author: ge0ffrey): Pr with reproducing unit test submitted. https://github.com/droolsjbpm/drools/pull/1131 > Match.getObjects() should also include accumulate's objects > ----------------------------------------------------------- > > Key: DROOLS-1470 > URL: https://issues.jboss.org/browse/DROOLS-1470 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta6 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Given this DRL: > {code} > global java.util.List list > rule R when > $t : CarType(id == \"roadster\") > accumulate( > $c : Car(type == $t); > $total : count($c) > )\ > then > list.addAll(kcontext.getMatch().getObjects()); > end > {code} > and then inserting the roadster type and 3 cars of that type: > {code} > CarType roadsterType = new CarType("roadster"); > ksession.insert(roadsterType); > Car bmwZ4 = new Car("BMW Z4", roadsterType); > ksession.insert(bmwZ4); > Car lotusElise = new Car("Lotus Elise", roadsterType); > ksession.insert(lotusElise); > Car mazdaMx5 = new Car("Mazda MX-5", roadsterType); > ksession.insert(mazdaMx5); > {code} > then the Match.getObjects() (or getObjectsDeep()) should include every Car instance too. > Let's discuss. Maybe we need a new method getObjectsDeep() instead if we can't change getObjects() for backwards compatibility reasons. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1470) Match.getObjects() should also include accumulate's objects

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1470?page=com.atlassian.jira.plugi... ] Geoffrey De Smet edited comment on DROOLS-1470 at 3/8/17 6:21 AM: ------------------------------------------------------------------ Pr with reproducing unit test submitted. https://github.com/droolsjbpm/drools/pull/1131 was (Author: ge0ffrey): Pr with reproducing unit test submitted. > Match.getObjects() should also include accumulate's objects > ----------------------------------------------------------- > > Key: DROOLS-1470 > URL: https://issues.jboss.org/browse/DROOLS-1470 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.0.0.Beta6 > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > Given this DRL: > {code} > global java.util.List list > rule R when > $t : CarType(id == \"roadster\") > accumulate( > $c : Car(type == $t); > $total : count($c) > )\ > then > list.addAll(kcontext.getMatch().getObjects()); > end > {code} > and then inserting the roadster type and 3 cars of that type: > {code} > CarType roadsterType = new CarType("roadster"); > ksession.insert(roadsterType); > Car bmwZ4 = new Car("BMW Z4", roadsterType); > ksession.insert(bmwZ4); > Car lotusElise = new Car("Lotus Elise", roadsterType); > ksession.insert(lotusElise); > Car mazdaMx5 = new Car("Mazda MX-5", roadsterType); > ksession.insert(mazdaMx5); > {code} > then the Match.getObjects() (or getObjectsDeep()) should include every Car instance too. > Let's discuss. Maybe we need a new method getObjectsDeep() instead if we can't change getObjects() for backwards compatibility reasons. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017