Whatever approach is used a standard schema is required, even if it is
implicit. Unless a service only supports PSOs that are suspendable (not a good
assumption), there has to be a way for a client to know what PSOs can be suspend
and what can't. That implies knowledge about what object classes represent
suspendable objects. That implies a defacto standard schema regardless of
whether we explicitly define one or not.
I prefer explicit standard schemas to implicit ones.
Jeff Bohren
OpenNetwork Technologies
-----Original Message----- From: Gearard Woods
[mailto:gewoods@us.ibm.com] Sent: Thu 3/25/2004 4:34 PM
To: Jeff Bohren Cc: Gary Cole;
provision@lists.oasis-open.org Subject: RE: [provision]
PSO/Account/ProvisionedState
I think there's a fundamental difference here even though the intent may be
the same. Basically, we're all trying to model state and provide some kind of
standardized view of it to the outside world so that we can offer
interoperability. By placing state in the resource schema you have immediately
abandoned the possibility that arbitrary resource schema may be supported,
which I believe to be important. You are also now requiring a mapping from the
"standard" schema to the real resource schema. On the other hand, by placing
the emphasis on the service provider and providing an operational interface to
effect state changes, the provider can now apply its knowledge of the resource
to make the state change however it wishes to do so and places no restrictions
on the resource schema. Gerry
"Jeff Bohren"
<jbohren@opennetwork.com>
Gary,
I
think we can make an assumption that for a given PSO, an SPML client must be
able to determine it's object class. That seems to be a basic prerequisite
(and is supported in SPML 1.0 via the objectclass attribute).
For the
purposes of interoperability, the schemas should not be completely arbitrary.
The should be some kind of standard object classes that would form the basis
of all other schemas. I'm not sure how much should be defined by the standard
object classes, but at a mimimum it could define the state
attributes.
Of course of if this approach is taken, there is no real
difference between:
setProvisionedState (pso, stateAttribute,
newValue)
and:
modifyRequest (pso, stateAttribute,
newValue)
The two are semantically equivalent.
So we come full
circle back to SPML 1.0 with a standard schema. But it's been a nice
trip.
Jeff Bohren OpenNetwork Technologies
-----Original
Message----- From: Gary Cole [mailto:Gary.Cole@waveset.com]
Sent: Thu 3/25/2004 3:31 PM To: Jeff Bohren; Gearard Woods Cc:
provision@lists.oasis-open.org Subject: RE: [provision]
PSO/Account/ProvisionedState
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
-----Original
Message----- From: Jeff Bohren [mailto:jbohren@opennetwork.com]
Sent: Thursday, March 25, 2004 2:09 PM To: Gary Cole; Gearard
Woods Cc: provision@lists.oasis-open.org Subject: RE: [provision]
PSO/Account/ProvisionedState
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
-----Original
Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent:
Thursday, March 25, 2004 10:59 AM To: Gary Cole Cc:
provision@lists.oasis-open.org Subject: RE: [provision]
PSO/Account/ProvisionedState
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
Inactive hide details for "Gary Cole"
<Gary.Cole@waveset.com>"Gary Cole"
<Gary.Cole@waveset.com>
"Gary Cole"
<Gary.Cole@waveset.com>
03/25/2004 08:31 AM
To:
Gearard Woods/Irvine/IBM@IBMUS cc:
<provision@lists.oasis-open.org> Subject: RE: [provision]
PSO/Account/ProvisionedState
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
Inactive hide details for "Jeff Bohren"
<jbohren@opennetwork.com>"Jeff Bohren"
<jbohren@opennetwork.com>
"Jeff Bohren"
<jbohren@opennetwork.com>
03/24/2004 12:06 PM
To:
<provision@lists.oasis-open.org> cc: Subject: RE: [provision]
PSO/Account/ProvisionedState
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
<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 <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 <http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php>
.
<<pic17332.gif>>
|