All of these arguments could also be made for explicit calls for setting
password, password reset status, etc. How do we decide what should be set
explicitly and what should be by using standard operations on known
attributes.
Of course all of these operations are only meaningful for accounts, and
then not for all types accounts. Since the operations are only meaningful for
accounts, the only way a SPML client would knwo whether a specific operation was
applicable to a specific PSO would be to know the PSOs object class and knwo
from the schema that the object class in question is a form of account.
Since it needs to know that anyway, why not also use the same mechansim to know
what state attributes exist on the PSO?
Jeff Bohren
OpenNetwork Technologies
-----Original Message----- From: Gary Cole
[mailto:Gary.Cole@waveset.com] Sent: Thu 3/25/2004 2:56 PM
To: Gearard Woods Cc: provision@lists.oasis-open.org
Subject: RE: [provision]
PSO/Account/ProvisionedState
Okay, I think I understand. You'd prefer to see the richness of
account/provisioned object state modeled through simple operations. That
sounds like a reasonable way to manage state.
So,
rather than a bunch of well-known attributes ("exists", "disabled",
"disableDate", "enableDate", "expired", "expireDate") we'd have a bunch of
methods. Perhaps something along the lines of the
following:
boolean exists();
void setExists(boolean b);
boolean disabled();
void setDisabled(boolean b);
void setDisabled(Date d);
void setEnabled(Date d);
boolean expired();
void setExpired(boolean b);
void setExpired(Date d);
Is
this (roughly) what you mean? If so, that works for
me.
Gary
Gary, I haven't been arguing against making the state more rich,
that's perfectly fine. As I said in my last message, there is nothing to
stop an account schema exposing any level of state information it wants and
I'm not opposed to extending the state model that was proposed in
WS-Provisioning. Our submission recognizes the pivotal role of state in the
provisioning process by explicitly providing the means to modify and audit
transitions through a simple set of operations. This emphasis is what I
would like to retain. It seems to me that the argument is building for an
account schema that tries to encapsulate all possible options for state. To
use Jeff's example, one that might have flags for password reset and enabled
and perhaps locked all at the same time. To follow this argument to its
conclusion, I can see that the direction you are probably going is towards
the scenario where the modification of an account's state is a matter of
setting a slew of attributes to the desired values and then performing some
kind of modify operation. This is obviously close to the way that this is
commonly done today. It's very common however to see programmatic interfaces
for provisioning that include operations such as suspend and restore, and
there is obviously a set of simple state operations that provisioning
systems frequently perform. What I'm suggesting is that this is so central
to provisioning that it deserves to be made explicit in the operational
interface. Gerry
"Gary Cole"
<Gary.Cole@waveset.com>
I think Jeff made a pretty strong case that it
takes more than one attribute to represent the state of a provisioned
object.
Conflating multiple aspects of that state into a single
attribute causes either a loss of information (if you give one aspect of
state precedence over the others) or a "combinatorial explosion" of values
(if you try to cram all the aspects of state into a single value, or into a
set of tagged values). Either of these (a loss of information or an
explosion of values) makes a single state attribute hard to use (difficult
to interpret and manipulate) and even more difficult to
extend.
Could we say that the state of a provisioned object consists
of a *set* of attributes (rather than a single attribute)?
If so, then perhaps we
could agree to a reasonable "working set" of attributes to represent the
state of a provisioned object. I'd start the bidding with the "status
attributes" I mentioned for Account in PrOM.
I know you want to keep the
protocol separate from the object model. I believe that you consider the
protocol more essential than the object model. (For that matter, I suspect
that deep down I agree.) However, I think this makes it even more important
that the protocol have a robust way to represent the state of a provisioned
object. If the object model is "optional" or "secondary", then the protocol
must be able to stand alone.
I believe that managing the state of provisioned
objects is of primary importance to a Provisioning Service Provider. The
fact that WSProvisioning defines separate methods to access provisioned
state, and that WSProvisioning defines a state model, suggest that you may
agree at least to some extent.
I'll assert that agreeing to a set of attributes
(to represent the state of a provisioned object) is a lot easier than
agreeing to an entire schema for provisioned object(s). Industry practice
suggests de facto standards for account state on which we can
build.
Whaddya say? How about provisioned state being a set of
attributes? How bad would that be?
Gary
-----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent:
Wednesday, March 24, 2004 11:53 PM To: Jeff Bohren Cc:
provision@lists.oasis-open.org Subject: RE: [provision]
PSO/Account/ProvisionedState
These are both good points, but the notion of state in
WS-Provisioning was never meant as a replacement for state attributes that
the target schema might expose. The state enumerations and operations
provide a simple external model of the state of the provisioning data for a
resource. This allows clients to request things such as suspension of an
account for example, without having to have intimate knowledge of the
semantics of the account schema, where perhaps a particular attribute might
assume a particular value to indicate suspension. By allowing the service to
manage the state of the resource, the burden of manipulating specific
(perhaps even non-public as far as the RA is concerned) state attributes of
the resource is removed from the client.
This does not preclude the
resource itself from providing a rich set of state attributes. On the
contrary, it was expected that all possible aspects of the state of
resources would be too complex to model effectively. Again, this comes back
to the question of defining the ultimate, all-encompassing schema for an
account or user. My opinion still is that a kitchen sink approach will end
up being too complex and will map poorly to many resource schemas.
Additionally, we will then be forcing implementors to perform a mapping
which in my book is not ideal when they might already have a perfectly good
schema for their resource. Gerry
"Jeff Bohren"
<jbohren@opennetwork.com>
I agree with Gary that the
"state" should be represented in the PSO attributes as described by the
object model rather than explicitly represented in the protocol. My
reasons for this are:
1) SPML is intended for provisioning things
other than accounts, some of which may or may not have states.
2)
As Gary pointed out, there are a lot of attributes that together comprise
the state. Even when looking at just simple state attributes there may
orthogonal state transitions. For instance an account may have an
attribute that indicates that it is enabled but may have
another attribute that indicates that the password must be reset at next
login. Both are independent state attributes and both have different
state transitions.
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.Cole@waveset.com]
Sent: Wednesday, March 24, 2004 12:38 PM To:
provision@lists.oasis-open.org Subject: [provision]
PSO/Account/ProvisionedState
If I recall correctly, the IBM
proposal based on WSProvisioning had a separate set of methods to get and
set ProvisionedState. However, the provisioned state was a single
attribute.
I usually think of the state of a provisioned object (such
as an Account) as being more complex. In the PrOM strawman, the
Account class includes several sets of attributes.
To
identify the account, Account has "target", "name", and
"guid" attributes. The account is usually associated with some
target, has a name that is changeable, and may have an internal
identifier that is not supposed to change.
To represent
more traditional notions of status, Account has "exists", "disabled",
"disableDate", "enableDate", "expired", and "expireDate". The "exists"
attribute is needed because the PSP may not have created the account yet
(for example, the target may be unavailable, or the request could be
going through approvals), or because the account has been deleted
natively (i.e., without going through the PSP). The
other attributes are drawn from experience with traditional account
sources (such as Human Resources systems, RACF, Novell, and Unix
systems). Not all account sources support all attributes, and we
could add other attributes, but these attributes represent common
features of accounts.
To represent credentials, Account has
"password" and "certificate" attributes. Perhaps there should be
others, but these attributes represent common forms of
credentials.
Finally (and perhaps most controversially), Account
represents membership and privilege with "organization", "group", "role",
and "right" attributes. The PrOM draft explains that these
attributes represent only an account's *memberships* in organizations,
groups, roles, and rights defined by the target. (However, this
does not prevent a PSP from supporting organizations, groups, roles, or
rights as provisioned objects. Past experience suggests that this
can be difficult, but any vendor is free to do so.)
So, is all of
this stuff really provisioned state? I think so. With the
possible exception of "target" and "guid", which should not change once
an account is provisioned and the values are known, the other attributes
could be changed through the PSP or natively (i.e., without going through
the PSP). What is more, an attempt to change one of the values
(e.g., to disable an account) could fail, in which case the PSP might be
expected to remember the requested values and retry the operation or
report the failure. These attributes represent features of accounts
(provisioned objects) which a PSP is commonly expected
to manage.
So, should this kind of stuff show up in the protocol
or in the object model? I guess that I'd prefer to see it in the
object model, but I suppose it's more important to me that these kinds of
attributes shows up *somewhere*. If #getProvisionedState returned
these kinds of attributes rather than a single attribute, I expect that
would work for me.
Why not just leave it "open"? Why not
just let each target expose its own schema? Why impose a defined
set of attributes? Interoperability. I think an RA should be able
to ask a PSP to disable an account, or to schedule its disablement in the
future. I think we know enough about the domain to define a set of
attributes that is generally useful in managing provisioned objects.
This would in turn make SPML a more valuable standard.
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.
|