April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2693) Upgrade JBoss Marshalling to 2.0.0.Beta6

by David Lloyd (JIRA)

David Lloyd created WFCORE-2693: ----------------------------------- Summary: Upgrade JBoss Marshalling to 2.0.0.Beta6 Key: WFCORE-2693 URL: https://issues.jboss.org/browse/WFCORE-2693 Project: WildFly Core Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.0.0.Beta16 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ] Jan Kalina commented on WFCORE-2691: ------------------------------------ Hmm... look like I have to revisit just created PR... seting Halt for PR for now > Elytron modifiable realms should show existing identities in subsystem > ---------------------------------------------------------------------- > > Key: WFCORE-2691 > URL: https://issues.jboss.org/browse/WFCORE-2691 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta15 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: eap71_beta, filesystem-realm, security-realm > > Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in: > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"elytron\"), > (\"filesystem-realm\" => \"realm\"), > (\"identity\" => \"user\") > ]' not found", > "rolled-back" => true > } > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add > { > "outcome" => "failed", > "failure-description" => "WFLYELY01000: Identity with name [user] already exists.", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2692) Credential store has configuration in "uri" attribute.

by Peter Skopek (JIRA)

Peter Skopek created WFCORE-2692: ------------------------------------ Summary: Credential store has configuration in "uri" attribute. Key: WFCORE-2692 URL: https://issues.jboss.org/browse/WFCORE-2692 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Peter Skopek Assignee: Peter Skopek Priority: Critical Credential store has configuration in "uri" attribute. All parameters are in one string. It can be confusing and there is risk of typo (e.g. delimiter typo) In my opinion the main intention for it is to have general solution for custom implementation. *Current state* {code} /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/keystore.jceks?store.password=pass123;create.storage=true") {code} *Suggestion for improvement:* Better solution to achieve this could be use a map. e.g. some like that: {code} /subsystem=elytron/credential-store=credStore:add(cs-map={store.password=pass123, create.storage=true, store.file=path/to/cred/file}) {code} Now credential store name is in URI too, it can be get from resource name. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8602) Credential store has configuration in "uri" attribute.

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/WFLY-8602?page=com.atlassian.jira.plugin.... ] Peter Skopek moved WFCORE-2692 to WFLY-8602: -------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-8602 (was: WFCORE-2692) Component/s: Security (was: Security) > Credential store has configuration in "uri" attribute. > ------------------------------------------------------ > > Key: WFLY-8602 > URL: https://issues.jboss.org/browse/WFLY-8602 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Peter Skopek > Assignee: Peter Skopek > Priority: Critical > > Credential store has configuration in "uri" attribute. All parameters are in one string. It can be confusing and there is risk of typo (e.g. delimiter typo) > In my opinion the main intention for it is to have general solution for custom implementation. > *Current state* > {code} > /subsystem=elytron/credential-store=cs001:add(uri="cr-store://test/cs/keystore.jceks?store.password=pass123;create.storage=true") > {code} > *Suggestion for improvement:* > Better solution to achieve this could be use a map. > e.g. some like that: > {code} > /subsystem=elytron/credential-store=credStore:add(cs-map={store.password=pass123, create.storage=true, store.file=path/to/cred/file}) > {code} > Now credential store name is in URI too, it can be get from resource name. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2691: ------------------------------------------ We have dynamic resources similar to what seems to be contemplated here, see core-queue resources in the messaging-artemis subsystem. So it's doable. But the implementations we have are based on the management layer accessing locally available data, e.g. the in-vm messaging server. Accessing things like an ldap server is a whole different thing. We also have users who do things like JMX queries for ObjectName *.* which means for every mbean which means for every management resource. Which would mean for every relevant record in LDAP. And those users complain if their query is slow. > Elytron modifiable realms should show existing identities in subsystem > ---------------------------------------------------------------------- > > Key: WFCORE-2691 > URL: https://issues.jboss.org/browse/WFCORE-2691 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta15 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: eap71_beta, filesystem-realm, security-realm > > Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in: > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"elytron\"), > (\"filesystem-realm\" => \"realm\"), > (\"identity\" => \"user\") > ]' not found", > "rolled-back" => true > } > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add > { > "outcome" => "failed", > "failure-description" => "WFLYELY01000: Identity with name [user] already exists.", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-2691 at 4/19/17 4:08 PM: ------------------------------------------------------------------- My comment from the related JBEAP-9547 applies here too: The management kernel requires that a Resource object exists for any address against which an operation is executed. Those Resource objects need to be reachable from the parent Resource object (i.e. /subsystem=elytron/ldap-realm=ldapRealm) That might be a big problem for these resources each of which represents an item in an external system, since navigating through the resource tree can mean needing to identify all possible resources, which means remote calls and possibly massive numbers of children. For example, imagine this: /subsystem=elytron/ldap-realm=ldapRealm:read-children-names(child-type=identity) This is a Blocker issue, because the management API of this subsystem has to be correct. We can't ship with large potential design problems. was (Author: brian.stansberry): My comment from the related JBEAP-9547 applies here too: The management kernel requires that a Resource object exists for any address against which an operation is executed. Those Resource objects need to be reachable from the parent Resource object (i.e. /subsystem=elytron/ldap-realm=ldapRealm) That might be a big problem for these resources each of which represents an item in an external system, since navigating through the resource tree can mean needing to identify all possible resources, which means remote calls and possibly massive numbers of children. For example, imagine this: /subsystem=elytron/ldap-realm=ldapRealm:read-children-names(child-type=identity) This is a Blocker issue, because TP or no, the management API of this subsystem has to be correct. We can't ship with large potential design problems. > Elytron modifiable realms should show existing identities in subsystem > ---------------------------------------------------------------------- > > Key: WFCORE-2691 > URL: https://issues.jboss.org/browse/WFCORE-2691 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta15 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: eap71_beta, filesystem-realm, security-realm > > Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in: > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"elytron\"), > (\"filesystem-realm\" => \"realm\"), > (\"identity\" => \"user\") > ]' not found", > "rolled-back" => true > } > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add > { > "outcome" => "failed", > "failure-description" => "WFLYELY01000: Identity with name [user] already exists.", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2691: ------------------------------------------ My comment from the related JBEAP-9547 applies here too: The management kernel requires that a Resource object exists for any address against which an operation is executed. Those Resource objects need to be reachable from the parent Resource object (i.e. /subsystem=elytron/ldap-realm=ldapRealm) That might be a big problem for these resources each of which represents an item in an external system, since navigating through the resource tree can mean needing to identify all possible resources, which means remote calls and possibly massive numbers of children. For example, imagine this: /subsystem=elytron/ldap-realm=ldapRealm:read-children-names(child-type=identity) This is a Blocker issue, because TP or no, the management API of this subsystem has to be correct. We can't ship with large potential design problems. > Elytron modifiable realms should show existing identities in subsystem > ---------------------------------------------------------------------- > > Key: WFCORE-2691 > URL: https://issues.jboss.org/browse/WFCORE-2691 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta15 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: eap71_beta, filesystem-realm, security-realm > > Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in: > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"elytron\"), > (\"filesystem-realm\" => \"realm\"), > (\"identity\" => \"user\") > ]' not found", > "rolled-back" => true > } > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add > { > "outcome" => "failed", > "failure-description" => "WFLYELY01000: Identity with name [user] already exists.", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ] Jan Kalina moved JBEAP-10441 to WFCORE-2691: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2691 (was: JBEAP-10441) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta15 (was: 7.1.0.DR13) > Elytron modifiable realms should show existing identities in subsystem > ---------------------------------------------------------------------- > > Key: WFCORE-2691 > URL: https://issues.jboss.org/browse/WFCORE-2691 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta15 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: eap71_beta, filesystem-realm, security-realm > > Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in: > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"elytron\"), > (\"filesystem-realm\" => \"realm\"), > (\"identity\" => \"user\") > ]' not found", > "rolled-back" => true > } > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add > { > "outcome" => "failed", > "failure-description" => "WFLYELY01000: Identity with name [user] already exists.", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8598) Upgrade Narayana to 5.5.24.Final

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8598?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated WFLY-8598: ---------------------------------- Summary: Upgrade Narayana to 5.5.24.Final (was: Upgrade Narayana to 5.5.7.Final) > Upgrade Narayana to 5.5.24.Final > -------------------------------- > > Key: WFLY-8598 > URL: https://issues.jboss.org/browse/WFLY-8598 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8601) FileKeystore is hard to use with non-file-based keystores

by Jan Pazdziora (JIRA)

Jan Pazdziora created WFLY-8601: ----------------------------------- Summary: FileKeystore is hard to use with non-file-based keystores Key: WFLY-8601 URL: https://issues.jboss.org/browse/WFLY-8601 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 10.1.0.Final Reporter: Jan Pazdziora Assignee: Darran Lofthouse We are implementing JCA KeyStore provider to get certificates and keys via external process over the network: https://github.com/latchset/custodia-jca-provider However, code in https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... makes use of such code hard. It seems that FileKeystore has two modes of operation -- either alias is specified and then the KeyStore is treated as file (isKeyStore = true) which has to exist and it has to be able to list aliases, or the file is not required to exist (isKeyStore = false) but then alias cannot be specified (and if it is specified as alias attribute to <keystore> element, it is ignored). In case we'd like to be able to use our provider without additional configuration in java.security, we'd like to be able to specify alias to retrieve specified entry, especially since getting the list of aliases might be either slow (for large sets) or not possible. For that however, we need to go the isKeyStore = true route with path specified and file existing. Alas, when we try <ssl> <keystore provider="custodia-cli" path="/dev/null" alias="wildfly/server-ssl" keystore-password="thepassword" /> </ssl> then due to the extra check in WildFly's code, startup fails with Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYDM0083: The KeyStore /dev/null does not contain any keys. at org.jboss.as.domain.management.security.FileKeystore.assertContainsKey(FileKeystore.java:169) at org.jboss.as.domain.management.security.FileKeystore.load(FileKeystore.java:120) at org.jboss.as.domain.management.security.FileKeyManagerService.loadKeyStore(FileKeyManagerService.java:189) Please consider removing the if (isKeyStore) { assertContainsKey(loadedKeystore); } code from https://github.com/wildfly/wildfly-core/blob/master/domain-management/src... since existence of the keystore file does not guarantee that the keys will be stored in it and that the provider will be able to loop through them. The file might be just /dev/null or some config file of the provider. Ideally though, it should be possible to specify alias even for keystore which has no path specified. -- 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 April 2017