November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-756: -------------------------------- Thanks. > Elytron ldap-realm does not support recursive role search > --------------------------------------------------------- > > Key: ELY-756 > URL: https://issues.jboss.org/browse/ELY-756 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Affects Versions: 1.1.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > Scenario: > LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process. > In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm. > Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron. > See example of LDIF for LDAP server: > {code} > dn: ou=People,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=jduke,ou=People,dc=jboss,dc=org > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: jduke > cn: Java Duke > sn: Duke > userPassword: Password1 > dn: ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Roles > dn: cn=R1,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R1 > member: uid=jduke,ou=People,dc=jboss,dc=org > description: the R1 group > dn: cn=R2,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R2 > member: cn=R1,ou=Roles,dc=jboss,dc=org > description: the R2 group > dn: cn=R3,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R3 > member: cn=R2,ou=Roles,dc=jboss,dc=org > description: the R3 group > {code} > In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-756: --------------------------- Comment: was deleted (was: Yes, example above shows definition of the whole "roles" attribute - it configures whole group search. (attributes as-rdn+filter+filter-base-dn+to are not related to recursion)) > Elytron ldap-realm does not support recursive role search > --------------------------------------------------------- > > Key: ELY-756 > URL: https://issues.jboss.org/browse/ELY-756 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Affects Versions: 1.1.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > Scenario: > LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process. > In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm. > Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron. > See example of LDIF for LDAP server: > {code} > dn: ou=People,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=jduke,ou=People,dc=jboss,dc=org > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: jduke > cn: Java Duke > sn: Duke > userPassword: Password1 > dn: ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Roles > dn: cn=R1,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R1 > member: uid=jduke,ou=People,dc=jboss,dc=org > description: the R1 group > dn: cn=R2,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R2 > member: cn=R1,ou=Roles,dc=jboss,dc=org > description: the R2 group > dn: cn=R3,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R3 > member: cn=R2,ou=Roles,dc=jboss,dc=org > description: the R3 group > {code} > In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-756: -------------------------------- Yes, example above shows definition of the whole "roles" attribute - it configures whole group search. (attributes as-rdn+filter+filter-base-dn+to are not related to recursion) > Elytron ldap-realm does not support recursive role search > --------------------------------------------------------- > > Key: ELY-756 > URL: https://issues.jboss.org/browse/ELY-756 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Affects Versions: 1.1.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > Scenario: > LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process. > In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm. > Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron. > See example of LDIF for LDAP server: > {code} > dn: ou=People,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=jduke,ou=People,dc=jboss,dc=org > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: jduke > cn: Java Duke > sn: Duke > userPassword: Password1 > dn: ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Roles > dn: cn=R1,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R1 > member: uid=jduke,ou=People,dc=jboss,dc=org > description: the R1 group > dn: cn=R2,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R2 > member: cn=R1,ou=Roles,dc=jboss,dc=org > description: the R2 group > dn: cn=R3,ou=Roles,dc=jboss,dc=org > objectclass: top > objectclass: groupOfNames > cn: R3 > member: cn=R2,ou=Roles,dc=jboss,dc=org > description: the R3 group > {code} > In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ] Marek Kopecký closed WFLY-7210. ------------------------------- Resolution: Done Closing this jira, because PR for WFLY-7024 is merged. > Expose JAX-RS resources as children of the subsystem > ---------------------------------------------------- > > Key: WFLY-7210 > URL: https://issues.jboss.org/browse/WFLY-7210 > Project: WildFly > Issue Type: Feature Request > Components: REST > Affects Versions: 10.1.0.Final > Reporter: Guillermo González de Agüero > Assignee: Lin Gao > Attachments: after-wfly7024.png, hal-jaxrs.png > > > Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment: > [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean) > This makes it specially easy to navigate trough the web console (attached screenshot). > To read JAX-RS resources, the command would be: > [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources() > I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7649) Ensure initial context lookup using the "java:" prefix works with the new naming client

by Farah Juma (JIRA)

Farah Juma created WFLY-7649: -------------------------------- Summary: Ensure initial context lookup using the "java:" prefix works with the new naming client Key: WFLY-7649 URL: https://issues.jboss.org/browse/WFLY-7649 Project: WildFly Issue Type: Task Components: Naming Reporter: Farah Juma Assignee: Farah Juma Currently, using the new naming client to perform initial context lookup using the "java:" prefix will result in the following exception: {code} WFNAM00026: No provider for found for URI: java at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:334) at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123) at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113) at javax.naming.InitialContext.lookup(InitialContext.java:417) {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2028) Clean up testsuite Elytron registration

by Hynek Švábek (JIRA)

Hynek Švábek created WFCORE-2028: ------------------------------------ Summary: Clean up testsuite Elytron registration Key: WFCORE-2028 URL: https://issues.jboss.org/browse/WFCORE-2028 Project: WildFly Core Issue Type: Task Components: Test Suite Reporter: Hynek Švábek Assignee: Darran Lofthouse Priority: Blocker Fix For: 3.0.0.Alpha13 In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them.. Also re-enable the following test case: - * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7648) Allow configuration for ActiveMQ client thread pools

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-7648?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-7648: ------------------------------ Summary: Allow configuration for ActiveMQ client thread pools (was: Allow core thread timeout for client thread pool) > Allow configuration for ActiveMQ client thread pools > ---------------------------------------------------- > > Key: WFLY-7648 > URL: https://issues.jboss.org/browse/WFLY-7648 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7648) Allow core thread timeout for client thread pool

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-7648: --------------------------------- Summary: Allow core thread timeout for client thread pool Key: WFLY-7648 URL: https://issues.jboss.org/browse/WFLY-7648 Project: WildFly Issue Type: Feature Request Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7549) Component upgrade Hibernate Validator to 5.3.3.Final

by Guillaume Smet (JIRA)

[ https://issues.jboss.org/browse/WFLY-7549?page=com.atlassian.jira.plugin.... ] Guillaume Smet updated WFLY-7549: --------------------------------- Summary: Component upgrade Hibernate Validator to 5.3.3.Final (was: Component upgrade Hibernate Validator to 5.3.2.Final) > Component upgrade Hibernate Validator to 5.3.3.Final > ---------------------------------------------------- > > Key: WFLY-7549 > URL: https://issues.jboss.org/browse/WFLY-7549 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Guillaume Smet > Assignee: Scott Marlow > > Hi, > Hibernate Validator can be upgraded to the latest stable: Hibernate Validator 5.3.2.Final. > API wise, there are very few changes except to features that were experimental. > WildFly is currently using 5.2.4.Final. > Changes from 5.2.4.Final to 5.3.2.Final: > * bugfixes, some of them are only available in the 5.3.x branch so they are by themselves a good reason to upgrade; > * the ability to add dynamic payloads to contraint violations. See http://in.relation.to/2016/01/18/hibernate-validator-530-alpha1-out/ for more information. > * a new programmatic API for constraint definition and declaration: it replaces an experimental feature with something more consistent with the rest of Hibernate Validator APIs. See http://in.relation.to/2016/09/05/hibernate-validator-530-cr1-out/ for more information > * new translations of the builtin constraints messages > * various improvements to the OSGi support > * various improvements to the JDK 9 support > Full changelog: https://github.com/hibernate/hibernate-validator/blob/5.3.2.Final/changel... > Migration guide for 5.3 outlining the changes requiring attention when upgrading: https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_co... > I'm working on validating the upgrade in WildFly and preparing a PR. > -- > Guillaume -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1198) CLI does not resolve multiple properties if one property is undefined

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1198?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1198: ------------------------------------------------- Ivo Hradek <ihradek(a)redhat.com> changed the Status of [bug 1289316|https://bugzilla.redhat.com/show_bug.cgi?id=1289316] from ON_QA to VERIFIED > CLI does not resolve multiple properties if one property is undefined > --------------------------------------------------------------------- > > Key: WFCORE-1198 > URL: https://issues.jboss.org/browse/WFCORE-1198 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.4.Final > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 2.0.5.Final > > > https://bugzilla.redhat.com/show_bug.cgi?id=1289316 description: > {noformat} > Multiple property substitution is working with EAP 6.4.3+, however, if a variable amongst the multiple variables is empty or has no value, then the subsequent property in the CLI command is not substituted. > For example : > cat props.properties > ----------------------------------------- > PROFILE-NAME=TestProfile > SERVER-INSTANCE-NUMBER=TestInstance > APP-VERSION= > VAR=test > ----------------------------------------- > cat test.cli : > --------------------------------------- > /host=master/server-config=${PROFILE-NAME}${APP-VERSION}${SERVER-INSTANCE-NUMBER}${VAR}:add(auto-start=true, group="${PROFILE-NAME}${APP-VERSION}-server-group") > --------------------------------------- > and if I execute "./jboss-cli.sh --connect --file=test.cli --properties=props.properties" then I have the following in the host.xml ": > ---------- > ... > <server name="TestProfile${SERVER-INSTANCE-NUMBER}test" group="TestProfile-server-group" auto-start="true"/> > ... > ----------- > Note APP-VERSION had no value, and so the subsequent SERVER-INSTANCE-NUMBER was not properly resolved > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 November 2016