"enableDate" and "disableDate" are much more complicated issues that just
suspend and restore. Some resources, like Solaris, only support an
"expirationDate", working on the assumption that if the account exists it is
enabled. Others, like our UIdP accounts, have the equivalent of "enableDate" and
"disableDate". Still others support richer notions of controlling repeated
"periods of enablement" which reflect a schedule of when an account
can be accessed.
It's
hard to say how much of this should be put in a standard schema. But regardless
of how detailed you want to make it, the approach would be the same. A standard
base class would be defined that included a logically related set of attributes
for which normative behavior would assigned. For instance a "schedulable" base
class could be defined that a schedule of when the account is enabled.
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.
Jeff, did you get this? I keep getting
postmaster notifications that my email deliveries to your address
failed.
I still very much want to understand your
approach.
Gary
----- Original Message -----
Sent: Tuesday, April 06, 2004 9:47
AM
Subject: RE: [provision]
PSO/Account/ProvisionedState
Okay so far....
Wouldn't we call the attribute something more
specific than "state" (since we've already agreed that there are several
kinds of state)? This feels like the "disabled" attribute in
PrOM. (Or are you perhaps suggesting that there is only a single
"state" attribute, and that the set of interfaces that an object class
supports determines the valid set of values for
"state"?)
Suppose that Win2K supports immediate disablement
and Solaris does not. Further suppose that RACF
supports *scheduled* enablement and disablement, but that Win2K does
not. In PrOM, I proposed three attributes to represent these:
"disabled", "enableDate" and "disableDate".
How would RACF advertise its support
for immediate disablement/enablement AND scheduled
disablement/enablement?
Gary
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
-----Original
Message----- From: Gary Cole [mailto:gary.cole@waveset.com]
Sent: Monday, April 05, 2004 5:44 PM To: Jeff
Bohren Cc: provision@lists.oasis-open.org 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 -----
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
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
-----Original
Message----- From: Gary Cole
[mailto:gary.cole@waveset.com] Sent: Tuesday, March 30,
2004 7:02 AM To: Jeff Bohren; Gearard Woods Cc:
provision@lists.oasis-open.org 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 -----
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 -----
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
|