Grouper Developers Forum

[Tom Barton <>]

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.
> For example.
>
>
> 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:

https://mail.internet2.edu/wws/arc/grouper-users/2005-01/msg00017.html

> 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.

No.

> 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?

Tom