Re: [provision] PSO/Account/ProvisionedState

[Gearard Woods <gewoods@us.ibm.com>]

Gary,
State can be as complicated as necessary but I'm not sure that the WS-Provisioning state-related methods and enumerations are too far away from what you are talking about. The submission included five defined states (created, suspended, active, locked, terminated) that were not intended to be exhaustive, so it was left open to allow users to create their own. A set containing "exists", "disabled" and "expired" could easily be included in an enumeration. I guess I'm not sure why each would need to be a separate attribute but that's a minor detail. On setting or retrieving the times for each of these transitions, the WS-Provisioning approach was to treat these as read-only essentially, so the "lifecycle" portion of the spec dealt with that. I can definitely see the value for a client in being able to set the expiration date/time for an account for example so I think it would be useful to explore that some more.

I'm worried in general about any attempt to come up with a definitive schema for accounts. What we are talking about here is really "control" information that is useful to the provisioning system but in many cases has little to do with the target resource itself. My perspective is that we should isolate and model this control information and leave the account schema to the resources. I agree that we should be able to schedule account state changes but that will generally be performed outside the resource and not by the resource itself. I'm similarly concerned about any attempt to define a user schema since the representations of users are as varied as those for accounts.

If I could suggest in the light of this and the other discussions on the list today that we consider the relationships involved in the provisioning space as the interesting parts of the model, and leave the entities to those who would define their own. This might allow the spec to be cleaner and more widely applicable, and decouple the SPML from the schemas for users and accounts that others are working on. This might also serve to focus the spec on the real meat of the provisioning task which, in my mind, is more concerned with establishing relationships than defining the resources involved. I'm thinking along the lines of a set of well-defined relationships that we might publish as part of the standard, such as, for example:
Owner - Account/resource owners
Alias - Might allow multiple identities/entities to be associated as the same identity
Member - For groups, roles etc.

Or at a lower level even:
Dependency - Inter-target dependencies for example

I know the WS-Managability and WSDM people have always been fond of relationships. Maybe we could align ourselves with what they end up adopting and improve compatibility. Alternatively it would not be difficult to define our own simple model until some other standard emerged for these kinds of loosely coupled relationships. I would propose a separate interface definition that PSPs might implement to allow relationships to be retrieved and possibly defined. PSPs conforming with the relationship interface would be required to support the PSTC-defined relationship types. Actually, there might be a set of relationships that would be critical and required and perhaps a set that would not be required but you get my drift. This would be an optional interface that would overlay on top of the "core" PSP interface.
Gerry

"Gary Cole" <Gary.Cole@waveset.com>

"Gary Cole" <Gary.Cole@waveset.com> 03/24/2004 09:38 AM

To: <provision@lists.oasis-open.org> cc: 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_workgroup.php.