January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7583) Salted password cannot be set through CLI for Elytron filesystem-realm identity

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7583?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7583: ---------------------------------------- If this is confirmed as being a CLI specific issue the issue should be moved over to the WFCORE project. > Salted password cannot be set through CLI for Elytron filesystem-realm identity > ------------------------------------------------------------------------------- > > Key: WFLY-7583 > URL: https://issues.jboss.org/browse/WFLY-7583 > Project: WildFly > Issue Type: Bug > Components: CLI, Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Michal Petrov > > Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI. > Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue: > - {{bcrypt}} > - {{salted-simple-digest}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7877) Upgrade mod_cluster to 1.3.6.Final

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7877?page=com.atlassian.jira.plugin.... ] Radoslav Husar moved JBEAP-8218 to WFLY-7877: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7877 (was: JBEAP-8218) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: mod_cluster (was: mod_cluster) Affects Version/s: 10.1.0.Final (was: 7.1.0.DR10) > Upgrade mod_cluster to 1.3.6.Final > ---------------------------------- > > Key: WFLY-7877 > URL: https://issues.jboss.org/browse/WFLY-7877 > Project: WildFly > Issue Type: Component Upgrade > Components: mod_cluster > Affects Versions: 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Needed to bring in support for elytron SSLContext integration MODCLUSTER-562. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2181) Server doesn't start on Windows when started from path that contains space

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2181?page=com.atlassian.jira.plugi... ] Tomaz Cerar moved JBEAP-8216 to WFCORE-2181: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2181 (was: JBEAP-8216) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Scripts (was: Scripts) Affects Version/s: (was: 7.1.0.DR8) Affects Testing: (was: Regression) > Server doesn't start on Windows when started from path that contains space > -------------------------------------------------------------------------- > > Key: WFCORE-2181 > URL: https://issues.jboss.org/browse/WFCORE-2181 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > > If one installs his EAP(on Windows) to the location that has a space in the path(...\Program Files\...) is then unable to start it. > This is regression against EAP 7.0.0 and 7.1.0.DR7. > This issue could be caused by JBEAP-6182 ([https://github.com/wildfly/wildfly-core/pull/1886/files]) > Following error is printed > {noformat} > Error: Could not find or load main class Files\ModCluster_Workspace\jboss-eap-7.1\standalone\log\gc.log > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7583) Salted password cannot be set through CLI for Elytron filesystem-realm identity

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/WFLY-7583?page=com.atlassian.jira.plugin.... ] Michal Petrov commented on WFLY-7583: ------------------------------------- The problem is in CLI, the command is not parsed properly: {{\{iteration-count=42,password=passwrod1,salt=bytes\{0x31,0x32,0x33\}\}}} is parsed as {code} [ { iteration-count=42, password=passwrod1, salt=bytes{0x31 }, 0x32, 0x33 ] {code} > Salted password cannot be set through CLI for Elytron filesystem-realm identity > ------------------------------------------------------------------------------- > > Key: WFLY-7583 > URL: https://issues.jboss.org/browse/WFLY-7583 > Project: WildFly > Issue Type: Bug > Components: CLI, Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Michal Petrov > > Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI. > Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue: > - {{bcrypt}} > - {{salted-simple-digest}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7583) Salted password cannot be set through CLI for Elytron filesystem-realm identity

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/WFLY-7583?page=com.atlassian.jira.plugin.... ] Michal Petrov reassigned WFLY-7583: ----------------------------------- Component/s: CLI Assignee: Michal Petrov (was: Darran Lofthouse) > Salted password cannot be set through CLI for Elytron filesystem-realm identity > ------------------------------------------------------------------------------- > > Key: WFLY-7583 > URL: https://issues.jboss.org/browse/WFLY-7583 > Project: WildFly > Issue Type: Bug > Components: CLI, Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Michal Petrov > > Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI. > Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue: > - {{bcrypt}} > - {{salted-simple-digest}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-533) Handling of ModelControllerClient means there is no safe way to reload a process from the wildfly maven plugin

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-533?page=com.atlassian.jira.plugin... ] James Perkins commented on WFCORE-533: -------------------------------------- +1 I think any client wanting to use the CLI API's will need to implement the {{AwatierModelControllerClient}} interface. > Handling of ModelControllerClient means there is no safe way to reload a process from the wildfly maven plugin > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-533 > URL: https://issues.jboss.org/browse/WFCORE-533 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Tomas Rohovsky > Assignee: Jean-Francois Denise > > reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example: > {code} > if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource > /subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar) > :reload > end-if > {code} > I use jboss-as-maven-plugin for its execution and sometimes I get: {{Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}} > This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7865) We cannot define CS file location outside of EAP directory

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7865?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-7865: ---------------------------------------- [~hsvabek] Great. :) FYI, an expression works too for people who don't want to configure a fixed path that may not be valid in all environments. That can be handy for something with a well known system property like java.io.tmpdir: {code} [standalone@embedded /] /path=java.io.tmpdir:add(path=${java.io.tmpdir}) {"outcome" => "success"} [standalone@embedded /] /path=java.io.tmpdir:read-attribute(name=path,resolve-expressions=false) { "outcome" => "success", "result" => expression "${java.io.tmpdir}" } [standalone@embedded /] /path=java.io.tmpdir:read-attribute(name=path,resolve-expressions=true) { "outcome" => "success", "result" => "/var/folders/_6/kpk00m_142x4r75q8fr3kkfw0000gn/T/" } {code} We could consider adding java.io.tmpdir to the list of standard paths we always install. That might be a minor migration hassle though for people that already set it themselves. We reject configs that attempt to directly set the standard paths. It would be a somewhat bigger migration hassle for people that already set it themselves, but to a different value than what the system property says. They'd have to use a new name for the path if they want to keep their existing value. > We cannot define CS file location outside of EAP directory > ---------------------------------------------------------- > > Key: WFLY-7865 > URL: https://issues.jboss.org/browse/WFLY-7865 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Peter Skopek > Priority: Critical > > We aren't able define location of CS file outside of EAP directory. When user has CS file on NFS he isn't able to reach this file. > Define CS file location to JBOSS_HOME/Standalone/data directory: > {code} > /subsystem=elytron/credential-store=CredStore001:add(uri="cr-store://test/cs123.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.data.dir) > {code} > When I try set relative to TEMP directory: > {code} > /subsystem=elytron/credential-store=CredStore002:add(uri="cr-store://test/cs123.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=java.io.tmpdir) > {code} > I get this error > {code} > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"java.io.tmpdir\""], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore002 is missing [jboss.server.path.\"java.io.tmpdir\"]"] > }, > "rolled-back" => true > } > {code} > *NOTE:* > *relative-to* is resolved here https://github.com/wildfly-security/elytron-subsystem/blob/c223be428b9a6f... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-788) Elytron SASL factories don't follow contract from corresponding Java interfaces

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-788?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-788: ------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > Elytron SASL factories don't follow contract from corresponding Java interfaces > ------------------------------------------------------------------------------- > > Key: ELY-788 > URL: https://issues.jboss.org/browse/ELY-788 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > Labels: sasl > > Java [SaslClientFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] and [SaslServerFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] interfaces define where {{null}} parameters or {{null}} return values are allowed and which Exception types can be used in methods. Elytron implementation of SASL mechanisms doesn't follow this contract, which results in NullPointerExceptions. > E.g. > {code} > java.lang.NullPointerException > at org.wildfly.security.sasl.scram.ScramSaslClientFactory.getMechanismNames(ScramSaslClientFactory.java:119) > ... > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-857: -------------------------------- Well, if the identity principal is derived from user input by design, as its purpose is to allow re-obtain identity from realm later, described issue is *not a bug*. Maybe the issue is, realm should provide two different principals - principal for re-obtaining and principal - user identifier for applications... Am I correct, [~dmlloyd] ? > Elytron ldap-realm is not able to use LDAP attribute as principal > ----------------------------------------------------------------- > > Key: ELY-857 > URL: https://issues.jboss.org/browse/ELY-857 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta16 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > In Elytron ldap-realm is currently not possible to obtain username from LDAP attribute which is different than rdn-identifier. It means that username of identity is always the same as value of rdn-identifier attribute. > It can cause issues when ldap-realm is used for authentication and another realm is used for authorization since data for realm authorization can depend on assigned name during authentication. > Example: > It seems that ldap-realm cannot be configured for following scenario: User with credentials {{someUser}}/{{Password}} is authenticated and name {{AuthenticatedUser}} is assigned to them (e.g. when calling {{./jboss-cli.sh -c -u=someUser -p=Password ':whoami'}}, then {{AuthenticatedUser}} should be printed). Following ldif is used: > {code} > dn: ou=People,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=someUser,ou=People,dc=jboss,dc=org > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: someUser > cn: some User > sn: AuthenticatedUser > userPassword: Password > {code} > Mentioned ldif works correctly with legacy security solution. > This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-800) Support file in management operation

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-800?page=com.atlassian.jira.plugin... ] Jean-Francois Denise resolved WFCORE-800. ----------------------------------------- Resolution: Done Thank you [~jmesnil], the current support for streams could be used in this case. JF > Support file in management operation > ------------------------------------ > > Key: WFCORE-800 > URL: https://issues.jboss.org/browse/WFCORE-800 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Affects Versions: 2.0.0.Alpha6 > Reporter: Jeff Mesnil > Assignee: Jean-Francois Denise > Labels: affects_elytron > > Working on WFLY-4683, I want to add 2 management operations :export-journal and :import-journal that export/import the journal from the messaging-activemq server resource. > The :export-journal operation is similar to the :take-snapshot operation and it is acceptable that the dumped file (created internally by Artemis) is stored on the server-side in a well-know location > However, I'd like to pass such a file to the :import-journal (specified by a dump attribute) so that the admin does not need to copy the dumped file to the server's host (or many hosts in domain mode) before calling the :import-journal operation. > Currently, this is not doable since we can not add a stream to a management operation *from the CLI*. Instead, I have to implement a global command that will execute the client code to create the management operation, read the file and attach it to the operation as a stream. > Ideally, I would like to specify that my :import-journal takes a dump attribute with the ModelType.FILE (or .URL ?) so that our management clients (both CLI and Web) know that they must attach the stream of the file to the management operation. > This RFE is to simplify this use case and make it possible to use directly the CLI (and Web) console to upload files without having to create a dedicated client command for that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 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 January 2017