[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]