Title: Message
Take
for example two kinds of accounts; Win2K and Solaris accounts. Assuming that
both are a kind of account, but Win2K accounts can be suspended and restored,
where as Solaris accounts can not (some provisioning system support suspending
Solaris accounts via passwords, but for the purpose of this discussion I will
assume that is not the case for this PSP).
A
standard schema might define an object class for account which has the typical
uid/password attributes and it might also define an object class for anything
(account or otherwise) that can be suspended and restored. For instance the
following could be object classes in a standard schema:
Account
uid
password
Suspendable
state
Then a
PSP may publish a schema that defines Win2K and Solaris
accounts:
Win2KAccount : Account, Suspendable
SolarisAccount : Account
Thus
the RA could know a prior what PSOs support suspend and restore semantics. It
would be those PSOs that inherit the Suspendable class.
BTW,
this is all supportable in the SPML 1.0 standard.
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:]
Sent: Monday, April 05, 2004 5:44
PM
To: Jeff Bohren
Cc:
Subject: Re: [provision]
PSO/Account/ProvisionedState
Jeff,
I think the ball's in your court on this
one. I'm ready to agree, but I need help imagining what a standard
schema for state might look like, and how provisioned object classes would
declare the features they support. (Of course, I realize you've been
busy writing the Use Cases.)
Gary
----- Original Message -----
From:
Gary
Cole
To: Jeff Bohren
Cc:
Sent: Tuesday, March 30, 2004 10:36
AM
Subject: RE: [provision]
PSO/Account/ProvisionedState
I'm convinced. I see the
complexities of "program by exception", I see the elegance of making
this schema-dependent, and I see that this kind of
elegance has practical value in a network protocol.
So
what would a "standard" state schema look like? I just need a little
help imagining this.
Would the standard state
schema contain elements or attributes to represent the multiple facets
of provisioned object state? How would the schema for each object
class specify which facets of provisioned object state it supports?
Would the schema for each object class be target-specific?
Gary
-----Original Message-----
From: Jeff Bohren
[mailto:]
Sent: Tuesday, March 30, 2004
9:09 AM
To:
Subject:
RE: [provision] PSO/Account/ProvisionedState
This is essentially the same as the "program by exception" approach
that is sometimes used in software development. In most cases the
arguments for and against it are more stylistic and philosophical that
practical. However since this is a network protocol, not a software API,
there a several practical issues that must be
addressed:
1) A PSP could legitimately consider setting unsupported status
attributes to be an error. In the case of batch requests, this could
result in the RA needing to resubmit all or part of the original batch
request (if "continue on error" is not specified).
2) From the standpoint of minimizing network traffic, the RA must
have a way to determine if a specific PSO supports a specific state
attribute. This is a must because if the RA is going to present a set of
state options for an authorized user of the RA system, it must be able to
present the supported state options for each PSO, not all of them.
Fortunately this is easily supported via standard
schema.
3) This approach will make status logic more complex. How does the
RA differentiate between a successful attempt to change an unsupported
attribute versus a failed attempt to change a supported
attribute?
This all requires extra complexity that is frankly unnecessary. So
far no one has brought up any state issues that could not be easily
supported in SPML 1.0 with the additional of standard schemas. If we
created a standard schema that only addresses account state, the SPML 1.0
could start addressing this issue immediately without even needing SPML
2.0 to be in place.
By using SPML 1.0 with a standard "state" schema, the state
management would be explicit, efficient, standards based, and available
immediately. What more do you want in a network
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
[mailto:]
Sent: Tuesday, March 30, 2004
7:02 AM
To: Jeff Bohren; Gearard Woods
Cc:
Subject: Re: [provision]
PSO/Account/ProvisionedState
Could we discuss the identification
attributes for a minute, because I think that sets the stage for the
discussion of state attributes?
In the email that teed this all up, I
wrote:
>
> 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.
>
When I say "Account", I think of this as
roughly equivalent to "ProvisionedObject". (I realize that not all
features of Account apply to every provisioned object, but this
doesn't bother me too much because not all features of Account apply to
every account. Target accounts all different, but there
are also common features.)
Not every target supports "guid", but it's
common enough (especially among the modern targets) that it's reasonable
to model this as a common feature. We can simply leave "guid" null
or empty where it is unknown or unsupported.
I don't want to leave this
"open" (i.e., an entirely arbitrary
attribute) because guid is pretty common and very useful
in managing the account. Where guid is supported, it is the
preferred identifier. It is *very* handy to keep a guid as a
native identifier, since this helps in detecting native renames (and
distinguishing a 'move' from a 'delete' and an 'add'). Where the
target supports some kind of guid, I want to map that value to an
attribute that my management code recognizes.
I'm guessing that everybody basically buys
this premise, because the discussion has centered on the state-related
attributes. Here's the part where I step off the
ledge...
I think of the state-related attributes
we've been discussing in the same way: common and useful where
supported, harmless and empty if unsupported. For example, it doesn't bother me at all if a
particular class of provisioned object doesn't support "disabled", as
long as the value that comes back is harmless (e.g., empty or
"NOT_SUPPORTED").
It's common enough (not just for
accounts, but also for policies and other objects) to add
objects disabled and then enable them at a later date. This
is such a common aspect of management that I'd prefer to model this
explictly as a well-known aspect of state.
I'm interested to know what everyone
thinks. I'm not sure everyone will agree with this line of
reasoning, but if this explains where I'm coming from, then maybe you
all can use it to explain things to me.
Gary
----- Original Message -----
From:
Gary Cole
To: Jeff Bohren
Cc:
Sent: Friday, March 26, 2004 9:32
AM
Subject: Re: [provision]
PSO/Account/ProvisionedState
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 -----
From:
Jeff Bohren
To: Gearard Woods ; Jeff Larson
Cc: Gary
Cole ;
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:]
Sent: Thu
3/25/2004 6:01 PM
To: Jeff Larson
Cc: Gary
Cole; Jeff Bohren;
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
'
src="gif00002.gif" width=16>"Jeff Larson"
<>
"Jeff Larson"
<>
03/25/2004 02:20
PM
To: Gearard
Woods/Irvine/IBM@IBMUS, "Jeff Bohren"
<>
cc:
"Gary Cole"
<>,
<>
Subject: RE: [provision]
PSO/Account/ProvisionedState
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:]
Sent:
Thursday, March 25, 2004 3:35 PM
To: Jeff
Bohren
Cc: Gary Cole;
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>>
