If it's reasonably clear how one would accomplish the common operations I've described (and from what you say it should be), then I'm sure I'll be okay with it. I just can't get comfortable with the concept alone.
Gary
Jeff Bohren wrote:
Message A couple of points:- Since we are talking about SPML and not DSML, it should modify(id, "password", password) and modify (id, "status", 1). DN is one type of acceptable ID, but not the only one.- It is easy to argue that modify (id, "status", 1) easy and intuitive so long as the value "1" is clearly documented as the standard value for status being enabled. To me it certainly seems easier that specifying that when you create an account in disabled state you initialize "status" to 0, but then to enable it later you have to call enable (id). This is, of course, a value judgment.- Since we are discussing this in the context of SPML 2.0, there is no reason that what ever schema mechanism we use would not support enumerated types, so it is really something like modify (id, "status", "enabled")- You are correct that the core operations could not be used for things like validating passwords and what not, although they could be used for retrieving password policies, if they where represented as PSOs on the PST. Those are interesting problems. I could see a separate interface for those operations. But it seems that for the actions that can be accomplished using the core operations should be accomplished using the core operations.- You misunderstood my previous comment about LDAP. The comments was concerning different approaches about setting passwords. I did not mean to imply that LDAP could solve all provisioning problems. I understand that it can't. What I meant that we should look at emulating it's success for the things that it does well. And setting passwords is something that it does well.- There is clear historical evidence that when faced with a choice between two protocols, one of which has a simpler syntax, the protocol with the simpler syntax wins in the long run. Some examples include:LDAP vs. X.500 and WBEMSNMP vs. CMIPSOAP vs. CORBA, RMI, and DCOMActually this argument reminds me a lot of the SNMP vs. CMIP debates. SNMP was "simple" and CMIP was "rich". CMIP is dead. By coincidence SNMP is also the single most successful network management protocol ever, despite there being several other contenders. This is evidence that taking the approach of having a small set of operations that can be used to do complicated things is an approach that has successfully worked in the past and is likely to do so in the future.Jeff BohrenProduct ArchitectOpenNetwork Technologies, IncTry 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: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Tuesday, May 04, 2004 4:03 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] RE: Account-specific operations (was "Basic Operations...")
Jeff,
While it might be arguable that modify(dn, "password", password) is no less intuitive than setPassword(id, password), it's hard to argue that modify(dn, "status", 1) is more intuitive or easy to use than something like suspend(id). You might respond that standard schemas makes this easy but how would you, for example, define the value for an attribute that indicates suspension in this last example? Since SPML 1.0 schema does not support enumerations for attribute values, this would be a documentation problem presumably which I think makes it a lot less usable than an alternative, such as a specific operation.
As has been suggested before on this list, the pervasive use of LDAP speaks more to what was available rather than the suitability of LDAP to the task. We already have requirements that go well beyond what LDAP can handle and others that go beyond what SPML 1.0 can handle. I would like to see the evidence to the contrary that you suggest is available in abundance, disproving the assertion that specific operations are more intuitive than attribute manipulation. As an example, if we were to suggest a password management interface comprised of the following set of operations, what would the LDAP-based version look like I wonder? How simple and intuitive would it be?
validatePassword(id, password)
checkPasswordAgainstPolicy(password)
setPassword(id, password)
generatePassword(id)
As long as LDAP is held as the preferred model by some members of the committee, I think that at the very least all the cards should be on the table. In other words I think it's critical at this stage to have details on what the view of an LDAP/SPML1.0 approach with standard schemas really looks like. This argument has been coming up for quite a long time but there have been few, if any, details on how it would compare to a richer operational model. This is the single most divisive issue that this committee is facing in my opinion and we need more than just empty rhetoric if we are to make progress at the next F2F.
Gerry
"Jeff Bohren" <jbohren@opennetwork.com>
"Jeff Bohren" <jbohren@opennetwork.com>
05/04/2004 06:49 AM
To: <provision@lists.oasis-open.org>
cc:
Subject: RE: [provision] RE: Account-specific operations (was "Basic Operations...")
All password related information (the password, password reset status,
etc.) has to be optionally set on the provision provisioning request.
All the password related information, except the password itself, needs
to be readable as well.
By adding password operations we would essentially create a protocol by
which some information can be set using the standard CRUD operations,
but must be modified and read using an entirely different set of
password specific operations. That makes the protocol more complex and
harder to understand.
I have heard several people express the opinion that having an operation
called "set password" is somehow more intuitive and easier to understand
than using existing operations to set a password attribute. There is no
evidence of that and quite a lot of evidence to the contrary. LDAP is
the single most successful identity management protocol in use today,
and it uses setting a password attribute.
It seems to me we should emulate proven success where possible. If there
is a way that is simpler and clearer I'm all for it, but so far I have
not seen any arguments to that effect.
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: Cohen, Doron [mailto:Doron_Cohen@bmc.com]
Sent: Tuesday, May 04, 2004 4:06 AM
To: provision@lists.oasis-open.org
Subject: RE: [provision] RE: Account-specific operations (was "Basic
Operations...")
I agree that on one hand we do not want to limit ourselves to just
account provisioning but that does not require in my view the exclusion
of password management operations . That obviously require the schema to
allow the client to be able to know what operations are allowed for each
type of a PSO/PSTD and obviously relate to it. In fact there are some
cases when even CRUD operations can not be complete . For example, some
target would not allow a delete operation to take place but we still
like to have delete as a core operation.
Enriching the model we have with native operations that provide the SPML
implementer a easy to understand view of the "world of provisioning"
would not necessarily make the standard more complex , in fact it may
simplify the implementation by providing a more straight forward view of
the domain.
Doron
-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com]
Sent: Monday, May 03, 2004 10:41 PM
To: provision@lists.oasis-open.org
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_wor
kgro
up.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_wor
kgroup.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.
