Hey all!
Another good conversation everyone. Sadly I won't be
attending the F2F, so I thought I'd throw in my $0.02
beforehand.
I agree with the two general
sentiments:
1. Passwords are important enough to be included in the
spec.
2. Passwords are not common enough to all PSO's to make
explicit operations for them.
I do like the idea of having another interface for
this, but I'm a little concerned about how this mechanism would actually work. I
don't like the idea of having schema for some things and other mechanisms for
others.
That said, I think a Facet Pattern would solve this
quite nicely, and the same mechanism would be extensible to other PSO's (like
OU's, Groups and things) down the road if desired.
Finally, adopting a State model sounds like we are
going down the same road of making our own schema model vs. using something that
is already out there. Perhaps one of the BPM models would be a better choice,
since provisioning is very tied to workflow anyway? Or am I missing something
here (very likely)?
Of course, I could be easy swayed by more of these
insightful emails ... keep 'em comin'!
Have fun this week everyone!
-Sandy
---
Alex "Sandy" Walsh
VP R&D
Abridean Inc.
This is a pretty important question and I do not see
consensus either way. I therefore propose an agenda item (amongst
others) to discuss this at the F2F Thursday.
Darran
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.
|