OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [provision] potential "federated" use cases


Tom, thank you.  I think I now understand MUCH better what you mean.

Gary

ps. At some point in the future I may need to ask you more about  
privileges as natural-language constructs.  Offhand, the notion of a  
'privilege' seems like a higher-level semantic construct that would  
have to be mapped onto the more concrete notion of 'attributes'.   
However, it may be the case that something in SAML or XACML makes this  
kind of mapping much more natural than I expect.

On Sep 28, 2010, at 9:30 PM, Tom Zeller wrote:

>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]