Re: [provision] potential "federated" use cases

[Tom Zeller <tzeller@memphis.edu>]

> What does "federated group provisioning" mean?  Is this federated
> provisioning of groups?  Or is this provisioning of federated groups?  (What
> people several years ago called "federated provisioning" could be described
> more accurately as the provisioning *of* federation.  That is, an enterprise
> A creates a new identity (or finds an existing identity) within another
> enterprise B and links the identity in enterprise B to an identity within
> enterprise A.  The link--that is, the correspondence between the identity in
> enterprise B and the identity in enterprise A--was the *federation*.
>  Creating the link, and creating the account in some cases, was the
> *provisioning*.  The provisioning itself was not federated, unless perhaps
> the proxy account that the requester used was linked to an account in the
> provider's enterprise.)

We should probably start by defining "federation", from the InCommon FAQ :

"A federation is an association of organizations that use a common set
of attributes, practices and policies to exchange information about
their users and resources in order to enable collaborations and
transactions."

http://www.incommonfederation.org/docs/guides/faq.cfm

As you stated above, "federated provisioning" is more accurately "the
provisioning of federation", which I'll further summarize as "the
provisioning of linkages between objects in a federation". So
"federated group provisioning" is more accurately "the provisioning of
federated groups", and more precisely "the provisioning of linkages
between groups in a federation".

In higher-ed, we will likely leverage our existing federations to
establish the trust relationships between RAs and PSPs. I would call
this "federated provisioning", distinct from "the provisioning of
federation". "Federated provisioning" will be useful, for example, in
the use case from Anil John  (Emergency Response Case 3 - SPML
Operations on an Attribute Service) whereby federated attribute
services are searched.

So, more accurately, I mean the federated provisioning of federated groups.

And, more specifically, I mean the provisioning of federated Grouper
groups, where Grouper is an Internet2 groups management software
effort. As far as Grouper is concerned, we are more likely to link
groups in a federation by storing external group information in a
local database, rather than referring to external groups via
references, largely for performance reasons. Once the link between
groups in a federation is established, we also want to use SPML to
provision changes made to a federated group in its source Grouper
installation to target Grouper installations.

Here is an existing wiki page regarding federated Grouper group provisioning :

https://spaces.internet2.edu/display/GrouperWG/LDAPPC-NG+Development

> Provisioning of access privileges and other privileges could be handled in
> SPMLv2, off the top of my head, only as:
> A) in the DSML profile, provisioning of attributes that represent privileges
> B) in the XSD profile, provisioning of XML elements or attributes that
> represent privileges
> C) in the DSML or in the XSD profile, provisioning of Capability-specific
> data.
>
> I can see that a XACML profile of SPML might simplify the management of
> access privileges and other privileges.

Although it seems that eventually everything is provisioned as an
attribute, there may be a case for representing privileges as natural
language constructs.

> I would be very interested to understand more about how SPML requesters and
> providers might leverage existing SAML federations.  I certainly agree that
> SAML's Change Notify proposal is interesting.  If extensions to SAML could
> render SPML unnecessary, then we should explore this opportunity for
> convergence.

Some folks in higher-ed do not like SPML, because it is "a mess" or
"no one uses it". One alternative is SAML based attribute services.
While my personal opinion is that SPML is quite useful, I take care to
represent the opinions of those that seek SPML alternatives. I think
that something along the lines of "provisioning assertions" leveraging
SAML would make use of existing federations to allow for federated
provisioning. Eventually, a target will most likely perform CRUD
operations, which do not exist (AFAIK) in SAML and are dealt with at a
high level by the Change Notify proposal - so there's room for SPML.

> Will you be able to describe some of the use-cases for federated group
> provisioning and privilege and access management?

Some of that work is in progress, I'll try, I need to ping collaborators.

My interest and involvement in the PSTC is an outcome of a meeting
held this past summer in Raleigh, NC, where attendees agreed that we
want an open-source federated provisioner (#16 on
https://spaces.internet2.edu/display/ACAMPActionItems/Home). We are
pleased that the PSTC has restarted.

Tom