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 Bohren
OpenNetwork 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 -----
Sent: Monday, May 03, 2004 4:59
PM
Subject: 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.
Gerry
Gary P Cole
<Gary.P.Cole@Sun.COM>
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>
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.
|