[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
[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
[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
[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
[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
[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
[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