On 03/30/2012 03:52 PM, Scott Seago wrote:
Rather than paste in the entire text, I'm just linking to the
wiki
writeup. Please read the whole thing first and if you want to
comment on anything specific, quote it and comment on this thread.
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Adding_Permiss...
Scott
In "LDAP Groups" mode we won't pull in all user groups
from the LDAP
server, as there may well be many groups that aren't related to
Conductor use, so we'll have an "Import LDAP User Group" action,
analogous to "Create User Group" action for standalone. This will
bring up a list of LDAP groups exposed by the LDAP server, allowing
the admin to choose one (or more? -- not sure if we'll allow
multiple groups at once yet) to import. The UserGroup will be created
in conductor, with the memberships pulled into Conductor at the same
time. Any group members that are not yet imported into the Conductor
database as Conductor users will be pulled in at the same time.
"Import LDAP User Group" action implies that an admin has to manually
add a new group in conductor anytime the group is added on LDAP server?
It would be nice to have both user and group lists configurable just by
setting ldap query (in config file).
For sync-on-use, the idea is we would store a "last sync
time" every
time we re-sync group memberships. Any time we make a permissions
check, the checking code would call a method on Group to refresh if
necessary (i.e. refresh if last refresh was longer ago than
$refresh-interval, otherwise return and do nothing).
Group.refresh_from_ldap_if_necessary would block while checking last
sync time and (if necessary) while performing the update using an
ActiveRecord pessimistic lock on the "last refresh time" data element
in order to prevent more than one web UI front end process (or
thread) from attempting to re-sync at the same time.
-1 for this (+1 for doing this on background), I experienced many
situations when customer's LDAP server was responding too slow. Typical
real-life situation is: LDAP is used for SMTP auth, SMTP server is
overloaded -> LDAP responses are slow. IOW slow LDAP is much more common
then it would be expected.
We have other background tasks anyway, so there is not much additional
work to do this on background.
Jan