OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [provision] PSO/Account/ProvisionedState


Title: Message
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]
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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]