jclowser at unitedmessaging.com 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).
