[Fedora-directory-users] Ideas for fds

[jclowser at unitedmessaging.com]

David Boreham wrote:

> Instead, the idea I had was to require that the application instead 
> simply
> read attribute(s) on the user's entry, and do what it needs to do 
> based on
> their values. For example the VPN app would read an attribute called
> 'allowVPNAccess', and if it had the value 'true', then it would allow 
> the user
> access.

Roles are great if I'm looking for a yes or no answer - i.e. do I have 
role x or not?  Sometimes that's not enough.  To give a couple examples...

In the case of the VPN Template (and I only worked on this briefly a 
couple years back), I believe the checkpoint stuff worked like this:

1.  They created a new vpntemplate schema extension of groupofuniquenames
2.  This extended group had attributes to limit times, hosts, and a 
bunch of other things they could access when connected to the VPN.
3.  When a user logged into the VPN, it would auth the user, then search 
for  something like 
(&(objectclass=vpntemplate)(uniquemember=<authedusersdn>)).
4.  If that returned a group, these other attributes in the returned vpn 
group define what access the user has.


I wrote a web admin tool that we use for our customers here that uses a 
similar concept:
1.  I created an extention of groupofuniquenames to create an "admin" group.
2.  This admin group has attributes to contain:
    - a "template" (a reference to a php file that does something like 
user admin, group admin, etc).
    - settings for the template (i.e. email domain to use, quota 
options, etc.)
3.  Different users may be members of different templates for user admin 
(say, full user admin template,
     password admin template, etc), and settings allow me to reuse 
templates for different customers
     (same template, but different search bases for users, different 
quota options, different dns domains
     for email, etc)
3.  When a user logs in, it searches for 
(&(objectclass=admingroup)(uniquemember=<usersdn>))
     to see which admin capabilities the user has, and how those 
capabilities are applied.
4.  For each admin group I find, I read the template, settings, etc. and 
present a list of tabs - each
    admin group translates to a tab, and the extra attributes in the 
extended admin group tells it
    the name of the tab, what code to use in that tab, and config info 
to drive how that tab works.

There's more to it than that, but that's the basics.

If I used roles here instead, I could probably extend the role the way I 
extended groupofuniquenames.  Then, when I auth the user, I'd see the 
roles the user is a member of, and run through that list to see which 
are admin groups and get those settings there.  FWIW, this was more a 
case of showing how I'm using groups than why I need a better dynamic 
group - creating dynamic admin groups is probably not the best thing to 
do :).

 - Jeff