jclowser@xxxxxxxxxxxxxxxxxxx wrote:
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.
Interesting. This was what role-based-cos was designed for.
Would that have worked for this application ?
(user's role drives cos, which returns a set of attribute values
on the user's entry from cos).
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
