From: Darran Rolls [mailto:Darran.Rolls@Sun.COM]
Sent: Tuesday, May 04, 2004 11:05 PM
To: 'Jeff Bohren'; provision@lists.oasis-open.org
Subject: RE: [provision] RE: Account-specific operations (was "Basic Operations...")
From: provision-return-531-darran.rolls=waveset.com@lists.oasis-open.org [mailto:provision-return-531-darran.rolls=waveset.com@lists.oasis-open.org] On Behalf Of Jeff Bohren
Sent: Monday, May 03, 2004 9:10 PM
To: provision@lists.oasis-open.org
Subject: RE: [provision] RE: Account-specific operations (was "Basic Operations...")First, is any one seriously considering limiting SPML 2.0 to just account provisioning?If not, how do we determine what is an account and what isn't?Jeff BohrenOpenNetwork Technologies-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM]
Sent: Mon 5/3/2004 7:29 PM
To: Gearard Woods
Cc: Jeff Bohren; provision@lists.oasis-open.org
Subject: Re: [provision] RE: Account-specific operations (was "Basic Operations...")Actually, I'm encouraged in several ways. If the hotseat moves around, I take that as a good sign that we can avoid gridlock. I'm stirring the pot in the hope that this will help us get down to specifics.If we define operations for an optional PasswordManagement interface, that'd be just great. I like the idea of an operation to validate a password. An operation that generates a password (that is guaranteed to be valid) would also be useful.A more general State mechanism than suspend and resume sounds good, but I haven't heard any suggestions to address the limitations of a single-state model. I think that an account has more than one kind of "state". I fear that representing state with a single attribute will leads to a combinatorial explosion of values. Perhaps I'm mistaken about that and a simple state model will suffice.An explicit Rename operation is valuable in part because it explicitly separates name from ID. As you probably suspect, I believe that an ID should be unique, immutable, and meaningful only to the PSP that generates it. Name (and other target-specific identifiers such as GUID or DN or ROWID or UID or SID) should be distinct from ID.I'm okay with containers, although I've expressed some concern that the overuse of this abstraction could fog the spec. For example, I want Target to be more than just another container since it has special significance to the protocol and to the domain. I do agree that a simple relationship model could be useful.Thanks for pitching in.Gary----- Original Message -----From: Gearard WoodsTo: Gary P ColeSent: Monday, May 03, 2004 4:59 PMSubject: Re: [provision] RE: Account-specific operations (was "Basic Operations...")Gary,
It seems we all have to take our turn in the hot seat. I agree with you that password management naturally falls under provisioning, and I would like to see us take it on. I'm just concerned that it might be difficut to reach consensus on what it would look like, considering how difficult it is to come to agreement on the core of the provisioning task. On the other hand, password management might be a more clearly defined task so the interface might be less contentious.
On the subject of agreement on the core provisioning interface, I agree wholeheartedly that we should model the basic operations rather than require schema knowledge and attribute manipulation. However, I'd still prefer to see a more general state management interface than simply suspend and resume. Rename is fine but I prefer to view all provisioned data (or PSOs) as having an opaque identifier that is immutable over the lifetime of the object, and distinct from any target-specific identifiers. To me a rename operation smacks of an implicit organizational structure where rename is used to move entries to a different part of the hierarchy. I don't imagine that's what you had in mind though. Maybe we can discuss this further at the face to face?
While I agree with your priorities regarding "containers", I still think we can usefully model relationships such as organizational hierarchies and groups. I don't think we need to build them into a core data model, or into the core interface, but a simple relationship model could provide a lot of utility.
GerryGary P Cole <Gary.P.Cole@Sun.COM>
Gary P Cole <Gary.P.Cole@Sun.COM>
05/03/2004 01:29 PM
To: Gearard Woods/Irvine/IBM@IBMUS, Jeff Bohren <jbohren@opennetwork.com>
cc: provision@lists.oasis-open.org
Subject: Re: [provision] RE: Account-specific operations (was "Basic Operations...")
Well, if Gerry's going to broker peace between Jeff and me, I'll just have to declare myself overwhelmed by irony and assent. If everyone else is okay with it, I'm happy to settle for adding RENAME, SUSPEND and RESUME to the core interface.
We can define Password operations in a separate interface, or simply leave these unspecified. I think that the latter (that is, leaving password operations unspecified) would be a bit of a cop-out, but I'd rather have a limited agreement than no agreement.
Gary
----- Original Message -----
From: Gearard Woods
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Sent: Monday, May 03, 2004 3:20 PM
Subject: Re: [provision] RE: Account-specific operations (was "Basic Operations...")
I'd like to suggest again that we break out these different aspects into different interfaces so that we can allow optional facilities such as password management to be implemented where it makes sense. The core specification should include all of the common operations that we generally agree upon, if there is such a set of operations. Then a separate password management interface could be used where appropriate and implemented by those vendors who wish to support it. It seems that we're never going to reach agreeement if we try to make a single all-encompassing interface. In any event, whether bundled or separate, if we're going to take on password management I'd like to add to the service interface a little to include the means to confirm that a credential is correct and also a method to determine if a password is compliant with any password policies.
As for suspend and restore, we've been over this ground quite a bit before. I fall on the side of putting state management into the core interface because I think it is more common to support it than not. If there is some concern about certain targets not supporting particular states then some sort of dicovery mechanism to determine what states, if any, can be supported wouldn't be out of the question.
Gerry"Jeff Bohren" <jbohren@opennetwork.com>
;)
"Jeff Bohren" <jbohren@opennetwork.com>
05/03/2004 12:41 PM
To: <provision@lists.oasis-open.org>
cc:
Subject: [provision] RE: Account-specific operations (was "Basic Operations...")
Even if you assume (which I don't) that only accounts are provisioned,
there still needs to be a way to determine what kind of accounts support
what kind of operations. For instance Solaris accounts don't support
suspend/restore semantics. Also the difference between set and reset
password is not universal among system that use passwords.
Another interesting case would be provisioning accounts for which
passwords are meaningless altogether. For instance if an RA was making a
provisioning request to a PSP to create accounts strictly for the use
SAML, WS-Federation, or Liberty SSO, that account may never have a
password. In this case suspend/restore makes sense, but the password
operations don't.
Or you may be provisioning end user accounts for use by a web service
enforcement agent. The agent may authorize calls made on the part of an
end user by an authenticated client, where the client never actually
authenticated directly to the agent and does not have a password on that
system.
While I would agree that most provisioning operations on a given service
would concern accounts, that does not mean that other kinds of objects
can be given secondary status. That would severely limit the usefulness
of the spec for no benefit.
I would assume the following:
1) Not all PSOs are accounts
2) Not all PSOs that are accounts can be suspended
3) Not all PSOs that are accounts have passwords
4) Not all PSOs that are accounts and have passwords have password
expirations
Given those assumptions, I don't see any gain in including
suspend/restore and password semantics in the core SPML protocol. It
would only make thing more complicated than they currently are.
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 [mailto:Gary.P.Cole@Sun.COM]
Sent: Monday, May 03, 2004 2:54 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
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.
>
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.
