I'm not that hard-core about "exists", although
I do found it very useful.
In our product, the PSP uses this to record
whether each account has been provisioned. The master record (or virtual
identity, in our parlance) may not have been fully provisioned (or
reprovisioned) to that target, so it's important to know whether the account
already exists. The target may have been down, or it may be
that the target is updated only on a certain schedule.
The "exists" attribute is also used when the PSP
provisions to a target. If the "exists" attribute says that the account
already exists, the PSP performs an update rather than an add. In this
case, it is an error if the account is not found on the target. This
indicates that the account was deleted natively (without using the PSP).
Similarly, if the "exists" attribute says that the account does not already
exist, the PSP performs an add rather than an update. If the account
already exists on the target, this could be an error.
Reconciliation also uses the "exists"
attribute. Each account is classified by comparing what the PSP
believes to what the target says. If the PSP says the account exists and
the target agrees, then the account is CONFIRMED. If the PSP says the
account exists and the target says it does not, then the account is
DELETED. If the PSP says that the account does not exist and the target
says it does, the account is FOUND. If the PSP says that the account does
not exist and the target agrees, then the account is MISSING. Correlation
adds more slots to the classification scheme, but you get the idea.
Finally, it seems like an attribute like "exists"
might be useful in the result of a bulk "get". I'm sure that there are
other ways to represent the absence of a provisioned object, but if the result
needs to show what was supposed to be created (but does not exist or no longer
exists on the target), then an "exists" attribute might be handy.
Anyway, I'm pretty sure we can figure this out
later. The main idea on the table seems to be the approach of defining
multiple interfaces (and your suggestion that these be tied together with a
common schema).
Gary
----- Original Message -----
Sent: Friday, March 26, 2004 4:02
PM
Subject: RE: [provision]
PSO/Account/ProvisionedState
I am
not real comfortable about the "exists" state, as that seems to duplicate
functionality of asynchrous requests. I don't see a difference between a PSO
that is in state exists=false versus an add request to create a PSO where
the add request is in pending state.
One
good example is an "active" state. An object class called "suspendable" could
be defined that defines a state attribute called "active". Thus an object
class that had "suspendable" as one of it's base classes could be suspended or
restored using state operations. Thus an object class that respresented a SAP
account would inherit "suspendable" where as an object class the respresented
a Solaris account would not.
I
don't think a listSupportedState attributes is needed, since it would
duplicate what coudl already be accomblished via standard
schema.
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.
This sounds interesting. Defining
multiple interfaces (as Gerry suggests) sounds like a reasonable way to
tease apart the facets that interest some (but not necessarily all) of
us. Tying these to a common schema (as Jeff B suggests) seems like a
reasonable way to keep the whole thing from flying apart.
I need a little more help imagining how
we'd structure this. I wanted to define a bunch of common
state-related attributes, but Jeff B and others point out that not all of
these apply to all types of accounts. Perhaps none of these
state-related attributes (beyond "exists") apply to some kinds of
provisioned object.
I had imagined calling a method
like:
State
getProvisionedState(PSO-ID);
For an Account, I'd get back all the attributes
that apply:
<State psoId='ID'
exists='true' disabled='false' disableDate='NONE' enableDate='NONE'
expired='false' expireDate='DATE' />
For a provisioned object that supports only
"exists", I'd get back only "exists":
<State psoId='ID'
exists='true'/>
But it sounds to me from the discussion above,
that I might have to define a different schema for each combination of
attributes. Am I right about that, or could 'Stateful' contain our
"starter kit" of common state-related attributes?
Would each kind of provisioned object have
to define in its schema which state-related attributes it supports?
Or would I just call a different method (e.g.,
#listSupportedStateAttributes)?
Or could I figure this out just from
the set of attributes returned by
#getProvisionedState(PSO-ID)?
Sorry if I'm misunderstanding
your suggestion. If so,
perhaps we should talk offline (rather than email
everyone).
Gary
----- Original Message -----
Sent: Thursday, March 25, 2004 7:51
PM
Subject: RE: [provision]
PSO/Account/ProvisionedState
I would not be opposed to having mulitple provisioning interfaces,
provided it was tied to a standard schema that normatively defined what
interfaces where appropriate for what object classes. The clients still
need to know what interfaces would apply to what PSOs.
For example the SPML core operations could apply to all object
classes but the SPML state operations may only apply to an object class
that inherits from a "Stateful" object class in a standard schema (note
that SPML 1.0 supports multiple inheritance so this is easy). This way the
schema for the resource does not even need to extend an abitrary "Account"
schema, it merely needs to extend the "Stateful" schema.
Jeff Bohren
OpenNetwork
-----Original Message----- From: Gearard
Woods [mailto:gewoods@us.ibm.com] Sent: Thu 3/25/2004 6:01 PM
To: Jeff Larson Cc: Gary Cole; Jeff Bohren;
provision@lists.oasis-open.org Subject: RE: [provision]
PSO/Account/ProvisionedState
I agree that granularity of the calls is important and it really
shouldn't take 42 calls to determine the state of an object - a single
call should suffice. I think we can model state effectively and still
minimize the traffic needed to manage it.
Jeff (Jeff B) has also
raised the slippery slope argument, and my take on it is that we should
provide an interoperable way to do the things we feel are a core part of
the provisioning process. There is a line here between what is
horizontal to provisioning and what is resource-specific. State
management is obviously important and passwords have come up before,
although Jeff B would argue that state is not even relevant to most
resources and is only applicable to accounts.
The provisioning
process is obviously not the same thing to all people. We have
disagreement even down to the fundamentals of the provisioning model.
Perhaps a way to tackle these different viewpoints is to divide and
conquer. Imagine that we split up the problem into a number of
interfaces:
SPML core - Basic provision (add), deprovision
(delete), modify, list/search SPML state - An interface and schema
representing state management (lifecycle included or separate?) SPML
events - An interface and schema for event notifications SPML
password - Password management perhaps SPML relationships -
TBD
Implementors must publish core to be SPML compliant. They may
then in turn overlay any of the other interfaces to offer enhanced
provisioning capabilities. These would be simple interfaces with minimal
schema but would be complementary and all take advantage of the core
schema. Vendors who deal with directory-style interfaces need go no
further than the core interface while others may wish to offer the full
suite. Obviously these categories are just off the top of my head but
does this sound like an approach that has
promise? Gerry
"Jeff Larson"
<Jeff.Larson@waveset.com>
I haven't been following this that closely, but
I like aspects of both approaches. I like the notion that you can carry out near-universal
operations like disable, enable, and expire, in a schema independent way. But I also like the notion
that I can at least obtain the current state from the model so I don't have to make 42 web services
calls to get everything I want to display.
I guess as long as the
schema is arbitrary we can have it both ways. If I
choose to use fine grained
standard operations I can. If the PSP exposes the same
functionality through the
model, I can use that too, though I will be outside of the SPML
spec.
But we're on a slippery slope here. Almost every account
will have an associated password, email address, and full name. Do we then provide
individual operations to get
and set those so we can access them in an standard way without having to
be bothered with PSP specific
schema? How far does this go?
Jeff
-----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent:
Thursday, March 25, 2004 3:35 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
<<pic13953.gif>>
|