Account-specific operations (was "Basic Operations...")

[Gary Cole <Gary.P.Cole@Sun.COM>]

I've been thinking about this a lot lately (of course, this doesn't mean that I'm right, just that I'm trying), and I believe that provisioning is *and should be* account-centric.

The organizations, groups, roles, and rights defined by a target are relatively static.  The vast majority of the time, we are creating accounts.  These may *refer* to (or belong to) organizational units, groups, and roles, but they don't always *need* to.

I would assert that with respect to provisioning:
1) *accounts* are primary
2) account *memberships* in containers are secondary
3) *container* objects themselves are tertiary.

I really hope we can find a way to agree, because I think this is important.  We (all the PSTC members) have talked at cross-purposes occasionally, since each of us come from different points-of-view. 

We had a little bit of a breakthrough when we distinguished "white-box" from "black-box" PSPs.  

I'm hoping that the distinction between "internal" and "external" provisioning may do something like that again.  External provisioning is the simple case, in which services are well-defined and very few choices are exposed.  In such a case, you don't see the other enterprise's org tree, and you may not want to make your operations schema-dependendent.  However, you still need to be able to enable/disable the identity and set/reset/expire passwords.

Taking a different tack, let's look at it terms of necessity and sufficiency.  I think we'd all agree that it's *necessary* for a PSP to create accounts. Some might even argue that creating, deleting and modifying accounts is *sufficient* for a PSP.
It is NOT necessary for a PSP to create organizational units, although this is desirable.

If we can agree that it's okay for provisioning to be account-centric, I think we'll be money ahead.  This will make the protocol easier to understand, easier to adopt, and better adapted to the basic use cases.

Gary
----- Original Message -----
From: Jeff Bohren <jbohren@opennetwork.com>
Date: Monday, May 3, 2004 1:31 pm
Subject: RE: [provision] Basic operations (that should be explicit)

> 
> On the enable/disable and password operations I still have the same
> concerns as before. Specifically how does a client know for which PSOs
> those operations make sense. For instance our SPML service can be used
> to provision user accounts as well as organizations units and other
> object types. Obviously reset password does not make sense for
> oraganizational units.
> 
> Since it is too limiting to only support account provisioning in SPML,
> it does not make sense to me to include account specific 
> operations in
> the protocol.
> 
> Jeff Bohren
> Product Architect
> OpenNetwork Technologies, Inc
> 
> Try the industry's only 100% .NET-enabled identity management 
> software.Download your free copy of Universal IdP Standard Edition 
> today. Go to
> www.opennetwork.com/eval.
> 
> 
> 
> -----Original Message-----
> From: Gary Cole [Gary.P.Cole@Sun.COM] 
> Sent: Monday, May 03, 2004 2:06 PM
> To: provision@lists.oasis-open.org
> Subject: [provision] Basic operations (that should be explicit)
> 
> 
> I believe that certain basic operations should be explicit in the SPML
> protocol.  For one thing, this helps the protocol reflect the
> provisioning domain.  
> For another, it reduces dependence on schema.  
> 
> The most basic operations are CRUD:
> - Create
> - Rename
> - Update
> - Delete
> 
> We already have Add, Modify, and Delete, but I think that we 
> should call
> out Rename explicitly.  Renaming  has significant implications for the
> namespace and for references.
> 
> I think we should also have:
> - Enable
> - Disable
> - SetPassword
> - ResetPassword
> - ExpirePassword
> 
> I realize that one could almost perform an equivalent update by: 1)
> looking up the schema; and 2) finding the appropriate element or
> attribute; and 3) specifying an appropriate value.  However, that 
> methodwill differ for each PSP or target.  Basic operations should 
> be simple,
> and should not require schema knowledge.
> 
> What say you, grand mavens of provisioning?
> 
> Gary
> 
> 
> To unsubscribe from this mailing list (and be removed from the 
> roster of
> the OASIS TC), go to
> http://www.oasis-
> open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
> 
> 
> To unsubscribe from this mailing list (and be removed from the 
> roster of the OASIS TC), go to http://www.oasis-
> open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
>