Re: How to setup authentication for different user groups using APEX and LDAP

No, we don't use OID but the CentOS Directory Server (version 8.1), which appears to be a decendant of the Sun Java Enterprise System/iPlanet Directory server.

The one thing that stands out to me (having worked with the Sun/iPlanet product for a long time) is that there are no unique attributes. In the Sun product, the UID was enforced to be unique (perhaps due to our setup) throughout the database, but the Centos product apparently cannot do this. I'm not sure how that would work if there are two identical UIDs in different OUs, and the app tries to authenticate using the UID (as it does). This is why the developer wants to cascade through the different OUs.

Perhaps the CentOS DS can enforce uniqueness, but I simply failed to find the howto?

Cheers,
Tony

On 14/07/11 22:04, Ian Cary wrote:
> You don't say whether you are using OID or not so I'm not sure if this is
> applicable but what I do with OID and Apex is allow the user to
> authenticate and then use HTMLDB_LDAP.IS_MEMBER_OF to obtain the group
> membership. Once you have that it is straightforward to get the application
> to behave differently for different groups.
>
> Cheers,
>
> Ian
>
>
> dedba_at_tpg.com.au:
>
> G'day
>
> The environment is APEX in Oracle 10g (Express initially), and Centos
> Directory Server 8.1.
>
> One of our Apex developers is trying to use LDAP to authenticate users to
> his application. The complication here is that there are two distinct user
> groups. One group is the company staff, whereas the other group can contain
> students, customers, staff and selected members of the public. All users
> will have records in the same directory server, although not in the same
> branch of the directory tree. Group 1 (staff) has "administrator"
> privileges, that is access to all parts of the application. Group 2 can
> only log in to fill out specially customised forms.
>
> The method proposed to get about this is to attempt to authenticate the
> user as a staff member first, then to attempt authentication as a member of
> group 2 and fail if not succeed. For this, it is proposed to use two RDNs,
> say ou=ourPeople and ou=otherPeople, and do a search/bind with either of
> them as the base DN in order.
>
> I am thinking that this is not particularly flexible and perhaps there are
> better solutions out there. If, for instance, in the future management
> decides that we need a third group, say ou=theOtherMob, then the
> authentication code will have to be changed. I have tried to find examples
> or "best practices" online, but found nothing. If you have thoughts or have
> come across examples on how to set this up, can you please share them?
>
> Cheers,
> Tony
>

--
http://www.freelists.org/webpage/oracle-l