[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Account-specific operations (was "Basic Operations...")
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]