I agree that we should have the means
to represent relationships in the SPML
model . Relationships are very useful for many of the use cases we tend
to talk about and when we drill down to useful provisioning implementations and
scenarios, the ability to represent not only the organizational relationship of
a person/user/account but also other types of relations that include roles,
subscriptions and federation are important. Therefore, I would seek to include
it in the model as well.
Doron
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.
|