Jeff,
I think I hear you and Gerry telling me
(almost) the same thing.
Gerry
said:
> I think we're on (very) roughly the
same page. I would have some concerns about the granularity of these
> operations in a Web Services context
however. I would add that another reason we opted for a modifyState()
> with an extensible set of enumerations,
rather than the more finely-grained operations you list here, was to
avoid
> versioning of the interface
whenever unforeseen states need to be supported.
You
suggest that the objectClass of the PSO determines its schema.
For
the purposes of this specific discussion, the objectClass of the
PSO
determines the set of state-related attributes that it
supports.
That
would enable an RA to turn around and call something like:
String getProvisionedState(String
attributeName);
That
seems basically okay to me (and I think it addresses Gerry's concern with method
granularity).
I
suppose that leaves me with two questions:
1) How
do you get the schema for a provisioned object?
Is this as simple as
#getSchema(PSO-ID)?
2)
Must the schema be completely arbitrary (that is, up to the vendor or
implementer)?
Is there some way we can predefine some common
state-related attributes
(so as to encourage interoperability, to reduce
reinvention of the wheel,
and to make the protocol more useful "right
out-of-the-box")?
Gary
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.
|