Hello.
I've very recently been given the task of migrating an existing Radiator
installation from having its users in a plaintext file (AuthBy FILE), to
authenticating against LDAP.
This sounds straight forward enough, I'm somewhat familiar with AuthBy LDAP2.
Now, what gets me a bit confused is this: the current users textfile has
entries with various attributes. Often it's the same attribute for many
users, but not always. For example, some have Timetra-Cmd attribute
listing read-only commands.
Oh, and if possible, I'd prefer to _not_ store these directly in the LDAP
(if I can avoid extending the LDAP schema and avoid having to mess up the
user provisioning tool, I'd prefer that). What I'd like to accomplish
somehow is mapping the various userlevels to group-membership in LDAP. If
someone are a member of for example the group "timetra-full-admin" they'll
get a Timetra-Cmd set to one thing ,and if they're a member of
"timetra-read-only" they'll have it set to something else. Makes sense?
If I have to store the attribute values directly in LDAP, there's also a
high chance that whoever is provisioning users might make a typo of some
sorts. In other words: I don't want to "extract attribute X from LDAP, and
returns its exact value". Oh, and if I can avoid using Perl hooks, that
would also be a good thing for me :)
One way I've thought might work is having multiple AuthBy LDAP2-blocks
chained together, with different searchfilters and replying with specific
attributes, similar to this pseudo-code:
Auth-block1: if memberOf=timetra-full-admins" reply with attr
Timetra-Cmd="abcd", otherwise continue to next block
Auth-block2: if memberOf=timetra-read-only" reply with attr
Timetra-Cmd="efgh", otherwise continue to next block
...
no more blocks? Reject user.
Part of me thinks there's bound to be a better way than this, though. Can
anyone lend me a clue? :)
Regards
Eivind Olsen
eiv...@aminor.no
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator