...
Making any sense?
Best,
Bill
...
From: William G. Thompson, Jr. <wgthom@gmail.com>
Date: Wed, Feb 24, 2016 at 3:07 PM
Subject: Grouper
To: Tom Barton <tbarton@uchicago.edu>
Tom,
I'm not sure if I misunderstood your comments today about wanting to keep Grouper focused solely on group management, but I'd love to chat more about that if you have a moment sometime soon.
If "account provisioning" is left to some other component it will still need all the grouper power of group delegation, group math, loader, etc. in order figure out who should be provisioned. Why not let grouper take the final step and make it so.
I suspect that just managing incoming identity data, identity life cycle, and identifier assignment, etc will be enough for any person registry. And more practically most (and possibly all) institutions will be very slow to take on such a project. So in any case that gap in functionality will remain for quite a long time.
My current plan for IAM nirvana includes driving policy about account provisioning with grouper. This might not include "primary account" such as an LDAP DN in an EDS as required for primary authentication, but it will likely include every other system that needs "some identity data" (aka "an account") to function.
My current plan goes something like this:
1) assume a source of canonical identities (person registries are too hard, and everyone has one already!)
2) point grouper subject api at 1)
3) create base "reference groups" (constituents, courses, organizations, committees, offices, etc) mostly driven by systems of record and maintained by grouper loader.
4) implement access management policy (accounts and groups) using grouper group math magic to drive effective membership for "account groups", "authorization groups", and "other groups (like mailing lists, etc)" which maintain fidelity with target systems.
5) enjoy the afterglow. :)
Is this at odds with your vision for Grouper?
Best,
Bill