Grouper Developers Forum

[Tom Zeller <>]

> [AI] (TomZ) will define terms related to "federated" versus "external" group
> management on the wiki, to help clarify the issues.

> Chris summarized his writeup on Grouper and External Users:
> https://spaces.internet2.edu/display/GrouperWG/Grouper+external+users

> In many cases, institutions want the ability to allow “external” people
> (from outside of their institution) to to use their applications. This
> creates an identity management challenge: How to feed external subjects into
> a subject source?

> *Syncing Between Group Management Systems*
> Chris developed ideas on the wiki about sharing a group between more than
> one Grouper instance, or syncing between group management systems in
> general. This issue overlaps w Standard Group API concept.
> https://spaces.internet2.edu/display/GrouperWG/Syncing+groups+between+group+management+systems
> We can currently synch between Grouper and LDAP. But synching with another
> Grouper is a new issue

> TomZ raised the question: What’s difference between provisioned, federated
> and external?
> It was noted that there are minor differences that should be clarified.
> [AI] (TomZ) will define terms related to "federated" versus "external" group
> management on the wiki, to help clarify the issues.

I think we've defined "external" as "outside of an institution's idm
system", and "federated" as "external and resolvable".

An external (and not federated) subject's attributes are not
resolvable and therefore need to be stored in grouper. A federated
subject's attributes are (usually) resolvable and may be cached in
grouper for performance reasons or because the external idm system may
not be always available.

From a grouper instance's perspective, all subjects that are not of
its internal (gsa/isa) source are, in a sense, external.  An external
subject could then also be a group from another insitution's idm
system, preferably grouper but perhaps any system satisfying a common
group api. So, a group from an external grouper instance could be
considered a federated subject and resolved using the subject api.

However, an external group needs to be "shared" or "synced" because in
addition to attributes it also represents memberships. Therefore, a
federated group is different than a federated subject (member).  The
sharing or syncing of a group may use a provisioning mechanism. A
federated group may look and feel just like a local/internal group,
except perhaps for a scope (another column in a table) and the notion
that the shared/synced/provisioned group needs to be refreshed (via
push or pull).

So, federated is a subset of external, and federated groups must be
provisioned (using a soon to be defined mechanism), while federated
subjects (which are not groups) are not provisioned, they are resolved
(using the subject api) and perhaps cached.

Make sense ?