Hello Ramandeep, apologies for not answering this sooner. Somehow it slipped past.
On 11/20/2014 01:54 PM, raman nanda wrote: > I am using Fortress RC-34, has this issue been fixed in future releases ? > > There is an issue if you search by FQDN. > The scenario is as follows. > > Search for a Role > --- Get Role Occupants -- List<String> -- FQDN for user > ------ Search the user using this FQDN --Error occurs > > us.jts.fortress.FinderException: findUsers userRoot > *[ou=People,dc=equatellc,dc=com*] caught LDAPException=89 > msg=encodeSafeText value [*[email protected] > <[email protected]>,ou=People,dc=equatellc,dc=com*] invalid length [47] > > at us.jts.fortress.rbac.dao.unboundid.UserDAO.findUsers(UserDAO.java:980) > at us.jts.fortress.rbac.UserP.search(UserP.java:74) > at us.jts.fortress.rbac.ReviewMgrImpl.findUsers(ReviewMgrImpl.java:284) > at > com.equatellc.modules.security.LDAPOperations.searchUsers(LDAPOperations.java:577) > at > com.equatellc.modules.security.LDAPOperations.getUserEmails(LDAPOperations.java:452) > at > com.equatellc.modules.security.LDAPOperations.getUserEmailsForGroup(LDAPOperations.java:420) In fortress, user-role assignments are persisted in two different ways: 1. An attribute is stored on the user object that contains the role name and temporal constraints. 2. An attribute is stored on the role object containing the user dn. This is done for the following reasons: - It is more efficient to determine role assignments given a user with #1 - It is more efficient to determine role membership given a role with #2. - #2 coincides with traditional user/group membership security operations, i.e. Network Information Services (NIS) and other simple access control methods. - #1 is necessary to carry the additional data elements necessary for temporal evaluations The data format for #2 is standard which means the members must be stored in dn format. Additionally in order for fortress to be able to correctly process the role members it has to carry the list around in that format as well. So the question becomes should the dn info be exposed to the end user - and - is there a way to surface that info to the end user where only the userId is shown for a given role.
