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, these use-cases are very interesting.  I think that descriptions  
of these "federated" use-cases would be valuable.  Even where these  
use-cases do not require changes to SPMLv2, the examples that they  
provide would be instructive.

I would like to ask a few questions upfront.  Please forgive my  
ignorance, since some of the terms are unfamiliar to me:

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

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.

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.

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

Gary

On Sep 27, 2010, at 2:54 PM, Tom Zeller wrote:

> Potential use cases I am involved with are federated group
> provisioning and privilege & access management provisioning. So far
> these use cases do not seem to suggest changes to the SPMLv2
> specification, rather, they may serve as example implementations
> potentially of interest to other parties wishing to encourage SPML.
>
> A potential issue with regard to federated group provisioning that we
> see is how to manage the group namespace across enterprises. This is
> not really an SPML issue, since lookup and search operations will
> allow parties to resolve identifiers. A suggested "best practice" for
> federated group naming may result.
>
> Privilege & access management provisioning may use XACML as the SPML
> payload, potentially requiring us to work out an XACML profile to
> SPML.
>
> Federated provisioning, whether of groups or privileges, requires
> relationships between RA's and PSP's that in higher-ed should leverage
> our existing SAML federations - perhaps something along the lines of
> SAML "provisioning assertions", with SPML as payload of the SAML
> protocol. SAML's Change Notify proposal is interesting because it
> supports multiple profiles, including SPML. Further alignment of SPML
> and SAML may result in greater adoption of SPML in higher-ed,
> otherwise, there are those that think SPML will be rendered
> unnecessary by extensions to SAML.
>
> 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]