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
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
