January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1534) Generic command help uses resource type as its name

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1534?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1534: -------------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) > Generic command help uses resource type as its name > --------------------------------------------------- > > Key: WFCORE-1534 > URL: https://issues.jboss.org/browse/WFCORE-1534 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > I created a command named toto: > toto --help > SYNOPSIS > logger --help [--properties | --commands] | > (--category=<resource_id> (--<property>=<value>)*) | > (<command> --category=<resource_id> (--<parameter>=<value>)*) > [--headers={<operation_header> (;<operation_header>)*}] > logger is used everywhere in the command description, it should be the actual command name. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1752) The deployment-overlay command fails to redeploy affected deployments

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1752?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1752: -------------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) > The deployment-overlay command fails to redeploy affected deployments > --------------------------------------------------------------------- > > Key: WFCORE-1752 > URL: https://issues.jboss.org/browse/WFCORE-1752 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Alpha5 > Reporter: ehsavoie Hugonnet > Assignee: Jean-Francois Denise > > The deployment-overlay command fails to redeploy affected deployments if the runtime-name isn't the same as the deployment name. Since affected deployment to be redeployed should be running the couple runtime-name + enabled == true should be used to define which deployments are affected instead of using the deployment name since the name used in overlay is the runtime-name -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1613) Merge Parsers and Completers

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1613?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1613: -------------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) > Merge Parsers and Completers > ---------------------------- > > Key: WFCORE-1613 > URL: https://issues.jboss.org/browse/WFCORE-1613 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > Today we have multiple parsers and completers for the same kind of syntax. It implies that any evolution done at the syntax level, needs to be duplicated in multiple places. We would have a big maintainability gain if they were merged them all together. That would also be a big effort. > -- 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 Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-533?page=com.atlassian.jira.plugin... ] Jean-Francois Denise reassigned WFCORE-533: ------------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) > 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] (WFCORE-533) Handling of ModelControllerClient means there is no safe way to reload a process from the wildfly maven plugin

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-533?page=com.atlassian.jira.plugin... ] Jean-Francois Denise commented on WFCORE-533: --------------------------------------------- The problem is still there but this time the third party (maven plugin) as the chance to implement its waiting logic thanks to the CLI AwaiterModelControllerClient interface that a ModelControllerClient can implement. > 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: Alexey Loubyansky > > 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] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-857: --------------------------------- Note that the principal derived from the realm is not used in the final SecurityIdentity at all today. It is only used to be able to locate the identity within the realm itself, which may have a later function relating to self-service. > 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] (ELY-867) Masked password support cryptography usage

by Zoran Regvart (JIRA)

Zoran Regvart created ELY-867: --------------------------------- Summary: Masked password support cryptography usage Key: ELY-867 URL: https://issues.jboss.org/browse/ELY-867 Project: WildFly Elytron Issue Type: Bug Components: Passwords Reporter: Zoran Regvart Assignee: Darran Lofthouse I encountered couple of issues with cryptography used for password masking: * implementation of masked passwords drops initialization vector (IV) randomly generated by the {{javax.crypto.Cipher}} which makes unmasking (decryption) impossible. * the implementation is using the same algorithm for key derivation and encryption, which is not possible as there is no encryption support in {{javax.crypto.Cipher}} for PKDBF2 family of algorithms, they are supported only in {{javax.crypto.SecretKeyFactory}} -- 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 David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-857: --------------------------------- Today the principal is derived from the input for good reason: so that a SecurityIdentity's principal can always be used to recreate that identity. If we derive the authenticated principal from the output we can end up in situations where the principal from an SI results in a different identity when used to authenticate, whose principal in turn can result in another different identity, etc. So we'd need to solve this basic problem first. > 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] (ELY-865) Principal name from realms should not be pure user input

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-865?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-865: --------------------------------- At present, the Principal used should always be the result principal of the pre-realm rewriter, which should take care of issues such as case folding if necessary. Further discussion will be on ELY-857. > Principal name from realms should not be pure user input > -------------------------------------------------------- > > Key: ELY-865 > URL: https://issues.jboss.org/browse/ELY-865 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > > All security realm now provides user-provided username as realmIdentity principal. > That can be problem, if identity search is case-insensitive - for example: > * Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can act as two different users for application running on AS - it can be security problem > * the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory > * the same can probably occure for JDBC, if database column is defined as case-insensitive -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-630) jboss-cli.xml should include timeout of 30 seconds

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-630?page=com.atlassian.jira.plugin... ] Jean-Francois Denise commented on WFCORE-630: --------------------------------------------- [~trogers-rh], an element is now present in jboss-cli.xml. It is commented but it is easy for the user to understand what needs to be done to get a 30 secs timeout. I will close this issue as fixed. JF > jboss-cli.xml should include timeout of 30 seconds > --------------------------------------------------- > > Key: WFCORE-630 > URL: https://issues.jboss.org/browse/WFCORE-630 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Travis Rogers > Assignee: Jean-Francois Denise > Attachments: loop-cli-cmd.sh > > > Description of problem: > CLI commands use a default timeout of 5 seconds. Testing has shown that connection timeouts will occur with a timeout value this low. Recommended value is 30 seconds. > The following default setting should be added to $JBOSS_HOME/bin/jboss-cli.xml: > <connection-timeout>30000</connection-timeout> > Version-Release number of selected component (if applicable): > How to reproduce: > Loop calling the CLI executing a command. > Example command: > jboss-cli.sh -c --command=":read-attribute(name=server-state)" > Actual results: > Connection timeout error will eventually be thrown. > Expected results: > No errors due to connection timeout. -- 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