[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-856 at 1/2/17 10:42 AM:
---------------------------------------------------------
-This issue is similar to ELY-794 - it would be solved, if we could use any LDAP attribute as wildcard in filter of attribute mapping.-
*Edit:* Ok, we doesn't - as we cannot address entry by DN using filter, special attribute sounds more appropriate - for example:
{code:xml}
<attribute reference="memberOf" from="cn" to="rolesDn" role-recursion="2"/>
{code}
(will take entries given by memberOf of user attribute, puts its cn to rolesDn, repeat for entries given by memberOf of group attribute)
was (Author: honza889):
This issue is similar to ELY-794 - it would be solved, if we could use any LDAP attribute (or identity attribute) as wildcard in filter of attribute mapping.
(But we would need to be able to address entity of attribute by DN!)
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Simplified example:
> {code}
> dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
> dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> objectClass: group
> memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
> {code}
> Example for reproducing: (by olukas)
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {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: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works 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)
8 years, 9 months
[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-856:
---------------------------
Description:
Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
Simplified example:
{code}
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
objectClass: groupMember
memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: groupMember
objectClass: group
memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
{code}
Example for reproducing: (by olukas)
Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
{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: User
userPassword: Password
description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: thisUserIsNotUsed
cn: this User Is Not Used
sn: this User Is Not Used
userPassword: Password
dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles
dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: SomeRole
member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
{code}
Mentioned ldif works with legacy security solution.
This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
was:
Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
Example:
Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
{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: User
userPassword: Password
description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
objectclass: top
objectclass: person
objectclass: inetOrgPerson
uid: thisUserIsNotUsed
cn: this User Is Not Used
sn: this User Is Not Used
userPassword: Password
dn: ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: organizationalUnit
ou: Roles
dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: SomeRole
member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
{code}
Mentioned ldif works with legacy security solution.
This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Simplified example:
> {code}
> dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
> dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
> objectClass: groupMember
> objectClass: group
> memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
> {code}
> Example for reproducing: (by olukas)
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {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: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works 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)
8 years, 9 months
[JBoss JIRA] (DROOLS-1387) PHREAK is slower than ReteOO with accumulate and exists
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1387?page=com.atlassian.jira.plugi... ]
Tibor Zimányi commented on DROOLS-1387:
---------------------------------------
I think I can confirm this. I created the "same" benchmarks in kie-benchmarks using JMH (I used DRLs and fact inserts from [~tkobayashi]'s reproducer). I put it in my separate branch, which you can find here [1]. Please *DO NOT MERGE* it into upstream, because it contains changes in pom.xml's and other benchmarks that contain references to APIs available only in 7.x. I will create separate PR for upstream/master when needed. [~tkobayashi] could you please check my benchmarks if I migrated them correctly? My results when I ran the benchmarks locally on my computer are here [2] .
[1] https://github.com/baldimir/kie-benchmarks/tree/DROOLS-1387
[2] http://pastebin.com/dsAMv5x3
> PHREAK is slower than ReteOO with accumulate and exists
> -------------------------------------------------------
>
> Key: DROOLS-1387
> URL: https://issues.jboss.org/browse/DROOLS-1387
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
> Attachments: brms-perf-comarison.zip
>
>
> PHREAK is slower than ReteOO in case of:
> 1. with accumulate
> 2. with exists
> Attached test case brms-perf-comarison.zip contains 4 tests to compare the performance:
> ReteOO_Accumulate vs Phreak_Accumulate
> -> ReteOO is 30% faster than PHREAK in average
> ReteOO_Exists vs Phreak_Exists
> -> ReteOO is 30% faster than PHREAK in average
> You can run the test with
> {noformat}
> mvn -P BRMS640GA clean test
> {noformat}
> The example output:
> {noformat}
> Running org.mk300.brms.perf.Phreak_Accumulate
> 2016-12-27 16:51:40,280 INFO (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:51:42,322 INFO (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:51:42,519 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 0 tx/sec
> 2016-12-27 16:51:43,529 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 29,020 tx/sec
> 2016-12-27 16:51:44,533 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 159,216 tx/sec
> 2016-12-27 16:51:45,539 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 203,391 tx/sec
> 2016-12-27 16:51:46,539 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 202,453 tx/sec
> 2016-12-27 16:51:47,553 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 204,160 tx/sec
> 2016-12-27 16:51:48,555 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 199,914 tx/sec
> 2016-12-27 16:51:49,556 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 193,496 tx/sec
> 2016-12-27 16:51:50,557 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 200,377 tx/sec
> 2016-12-27 16:51:51,557 INFO (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 202,060 tx/sec
> 2016-12-27 16:51:52,522 INFO (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.394 sec - in org.mk300.brms.perf.Phreak_Accumulate
> Running org.mk300.brms.perf.Phreak_Exists
> 2016-12-27 16:51:52,860 INFO (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:51:54,521 INFO (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:51:54,716 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 0 tx/sec
> 2016-12-27 16:51:55,737 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 72,411 tx/sec
> 2016-12-27 16:51:56,737 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 257,065 tx/sec
> 2016-12-27 16:51:57,741 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 292,136 tx/sec
> 2016-12-27 16:51:58,746 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 283,862 tx/sec
> 2016-12-27 16:51:59,753 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 285,201 tx/sec
> 2016-12-27 16:52:00,753 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 290,762 tx/sec
> 2016-12-27 16:52:01,760 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 291,661 tx/sec
> 2016-12-27 16:52:02,760 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 296,011 tx/sec
> 2016-12-27 16:52:03,767 INFO (pool-1-thread-1) [PerfCounter] Phreak_Exists : 296,844 tx/sec
> 2016-12-27 16:52:04,719 INFO (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.004 sec - in org.mk300.brms.perf.Phreak_Exists
> Running org.mk300.brms.perf.ReteOO_Accumulate
> 2016-12-27 16:52:05,068 INFO (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:52:07,139 INFO (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:52:07,349 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 0 tx/sec
> 2016-12-27 16:52:08,368 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 50,996 tx/sec
> 2016-12-27 16:52:09,380 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 217,269 tx/sec
> 2016-12-27 16:52:10,391 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 252,807 tx/sec
> 2016-12-27 16:52:11,453 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 245,798 tx/sec
> 2016-12-27 16:52:12,457 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 225,747 tx/sec
> 2016-12-27 16:52:13,458 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 254,959 tx/sec
> 2016-12-27 16:52:14,487 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 249,093 tx/sec
> 2016-12-27 16:52:15,496 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 237,899 tx/sec
> 2016-12-27 16:52:16,517 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 237,790 tx/sec
> 2016-12-27 16:52:17,375 INFO (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.455 sec - in org.mk300.brms.perf.ReteOO_Accumulate
> Running org.mk300.brms.perf.ReteOO_Exists
> 2016-12-27 16:52:17,751 INFO (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:52:19,431 INFO (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:52:19,643 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 0 tx/sec
> 2016-12-27 16:52:20,656 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 99,934 tx/sec
> 2016-12-27 16:52:21,679 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 308,091 tx/sec
> 2016-12-27 16:52:22,700 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 331,749 tx/sec
> 2016-12-27 16:52:23,721 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 351,276 tx/sec
> 2016-12-27 16:52:24,721 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 351,285 tx/sec
> 2016-12-27 16:52:25,732 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 349,222 tx/sec
> 2016-12-27 16:52:26,746 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 339,559 tx/sec
> 2016-12-27 16:52:27,754 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 328,000 tx/sec
> 2016-12-27 16:52:28,756 INFO (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 328,937 tx/sec
> 2016-12-27 16:52:29,647 INFO (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.056 sec - in org.mk300.brms.perf.ReteOO_Exists
> {noformat}
> NOTE: These tests run in different JVMs (reuseForks = false in pom.xml) so the order of test execution doesn't affect the performance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-2122) [Deployment overlay] Missing possiblity to print overlay mapping
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2122?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-2122:
-----------------------------------------
Summary: [Deployment overlay] Missing possiblity to print overlay mapping (was: [Deployment overlay] Missing possiblity do print overlay mapping)
> [Deployment overlay] Missing possiblity to print overlay mapping
> ----------------------------------------------------------------
>
> Key: WFCORE-2122
> URL: https://issues.jboss.org/browse/WFCORE-2122
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Labels: UserExperience
>
> Problem
> I don't see any possibility to print mapping specified by argument --content in existing overlays.
> Proposed solution
> Provide such functionality. I see 2 levels of granularity
> 1. Display mapping in overlay only
> 2. Display real mapping in specific deployment (not all deployment has to have all files defined by overlay)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (DROOLS-1390) Inconsistent scanner state when using very small polling interval
by Petr Široký (JIRA)
Petr Široký created DROOLS-1390:
-----------------------------------
Summary: Inconsistent scanner state when using very small polling interval
Key: DROOLS-1390
URL: https://issues.jboss.org/browse/DROOLS-1390
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.0.0.Beta5
Reporter: Petr Široký
Assignee: Petr Široký
Priority: Minor
Using KIE Scanner state with very small polling interval (e.g. 20ms) may lead to inconsistent scanner state (race condition). Using such a small interval is not recommended, but the scanner state needs to be consistent even is such cases.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-856:
--------------------------------
This issue is similar to ELY-794 - it would be solved, if we could use any LDAP attribute (or identity attribute) as wildcard in filter of attribute mapping.
(But we would need to be able to address entity of attribute by DN!)
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Example:
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {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: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works 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)
8 years, 9 months