Hi,
a few days back (co-worker) Andres Tarallo asked a question about
multiple systems accounts assigned to a person, and Quanah suggested to
implement a Single Sign On.
I think it would be the best solution but for some other reasons we
can't do that.
So I'm begging for a "less bad" solution advice here.
We can create several accounts as auxiliary objects and add them to the
main person object or we can make them structural objects, so the
accounts will be hanging from the main person.
As Andrés and I are very new to this matter, we can't decide which
would be the better way.
Any suggestions are welcome.
Best regards, and sorry for my poor english.
Ernesto Silva.
Coordinador de Desarrollo Web y Sistemas Abiertos
Universidad ORT Uruguay.
E-mail: [EMAIL PROTECTED]
Tel: (+598-2) 902-1505 ext. 206
Quanah Gibson-Mount wrote:
>
>
> --On Friday, March 10, 2006 3:15 PM -0300 Andres Tarallo
> <[EMAIL PROTECTED]> wrote:
>
>> I'm in the process of designing and setting a new LDAP server for our
>> university. We're designing the tree structure, but we have some dubts
>> about it.
>>
>> We want to store in the tree contact information for all the people that
>> work and study at the university. People lie into three different
>> categories: staff, academic staff (teachers and researcher) and
>> students. Is not rare that a person belongs to two categories: a teacher
>> is part of the staff or a student is also a teacher or research
>> assistant. We want to enable access to certain resources based on user
>> category, we also need that when you search for a person you can find it
>> no matter which category he is . It doesn't make sense for dupplicating
>> date in each category: Do we have a more elegant solution?
>
> I would argue against separating people out based on affiliation (as
> another responder also noted). It is much better to track affiliations
> in an attribute in an entry rather than to organize people by those
> affiliations (especially since affiliations can also change).
>
> Stanford puts every person entry in a single tree:
> cn=people,dc=stanford,dc=edu.
>
> As noted, eduPerson may help you.
>
> You may want to browse the Stanford Tree structure for some ideas as well:
>
> <http://www.stanford.edu/services/directory/trees/>
>
>
>> We also have the problem that a perosn might have access to different
>> systems, soit might have a collection of passwords. Here we are dealing
>> with the idea of putting all the password in the same object or have
>> objects hanging from the owner.
>
> Well, I can only suggest implementing an SSO type system... It really
> solves a lot of problems.
>
> --Quanah
>
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITS/Shared Application Services
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>
> ---
> You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
> To unsubscribe send email to [EMAIL PROTECTED] with the word
> UNSUBSCRIBE as the SUBJECT of the message.
>
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
