Subject: Grouper Developers Forum
- From: Tom Barton <>
- To: John Ballem <>
- Subject: Re: [grouper-dev] some provisioning questions
- Date: Mon, 12 Sep 2005 17:27:26 -0500
I'll muse about uchicago's prospective deployment below. -Tom
John Ballem wrote:
I was wondering how folks are intending on handling some basic provisioning issues.
Especially as we have many of the same issues on both the loader and connector sides.
1) Is anyone concerned with latency?
Is a 24 hour turnaround sufficient for a group membership or not?
Or are more real time updates a requirement. Message queue requests perhaps.
Latency on the order of some minutes (1-15, perhaps) is about where I think it should be. A model in which provisioning connector pulls is sufficient, ie, although it'd be nice, we shouldn't need an asynchronous message-based push-provisioning environment.
2) What would you consider the smallest unit of update in such a system?
For example, subject, group, subtree or acl updates, or all/any of the above.
Each provisioning connector should examine and conditionally propagate every change occuring since the last polling cycle. No change is too small, and no change triggers a poll (strictly based on the clock for simplicity).
3) What do you perceive as the flow of business rules?
For example, is there to be a signet rule to provision a certain department?
I imagine that a grouper -> LDAP provisioning connector will provision all groups subordinate to a configured set of grouper namespaces. As LDAP is widely used here, that set of namespaces would essentially define the "production" areas of the groups registry. As new activities conducted under new namespaces get ready, their namespaces are added to the configured list. But I imagine that to be a not-very-often event.
I can imagine uses for having finer-grained control over what gets provisioned, as might be achieved using a signet-integrated provisioning connector. But what did you have in mind?
4) Ldap group access acls. Here at Brown we only use two methods 'ismember' and 'members'.
Is that to be controlled by application or more broader ldap bind administrative accounts.
I wrote the grouper-users list a while back about prospective means of mapping privs within the groups registry to LDAP ACLs:
5) As related to #3 how to we turn on ldap group population. Signet or another gui.
Should there be a push process that populates on demand as in #1.
See responses to #1 - #3 above.
Is anyone intending on using dynamic groups such as iplanet, client considerations.
6) Groups DIT naming.
Organization uniqueness or federated uniqueness?
I expect our group naming to be unique across uchicago. If a scenario for uniqueness within a federation emerges, I plan to prepend the registered "urn:mace:uchicago.edu:" to an as yet to be determined infix (maybe "group:") followed by the name attribute of the group as it appears in the groups registry. You may recall that that name is itself a ':' separated thingie (the namespaces within the groups registry are delimited this way), enabling it to be "lifted" to global uniqueness.
Are folks planning on aggregating groups bases on client considerations or access.
So a group branch that is populated with unique dn's for use by lists.
What about groups that may do lookups on login string or username?
I haven't yet focused on uchicago use cases in which static LDAP groups will be operative. Not even sure there are any actual ones as yet (could be if we ever change MLM technology, for example). There is one use case in hand for provisioning static groups outside of the groups registry, but not into a general purpose LDAP directory. Other such use cases appear to be forming as well.
7) Any pitfalls encountered already such as AD group membership exceeded.
Haven't tried it out yet. But I thought that the Windows 2000 limit of 5000 members per group (in some circumstances) has been lifted in Windows 2003. They're now essentially limitless. Can someone confirm?
- some provisioning questions, John Ballem, 09/12/2005
- Re: [grouper-dev] some provisioning questions, Tom Barton, 09/12/2005
Archive powered by MHonArc 2.6.16.