[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RESTful SPML: Scope of use-cases to address?
Part of the appeal of SCIM is that it is RESTful. Representing resources ("nouns) in a way that allows core operations to be accomplished using HTTP "verbs" (and allows other operations using special flavors of verbs such as POST) is an attractive design approach that works well with web technologies. Another part of the appeal of SCIM is that it defines a "standard schema" with some facility for extensions. However, at this time the SCIM draft describes mainly user-management use-cases, which is much smaller and simpler than the identity-management use-cases that drove the development of SPMLv2. I know that a single provider can support both RESTful and SPML "bindings". SPML as a protocol is verb-first, leaving open the "nouns": the schema of each target and the format of the payload. REST as an architectural principal is noun-first, leaving open exactly how to represent more advanced operations in terms of resources. These approaches are compatible, but I wonder how far we would want to go as a standard? Just as a thought-experiment: Would we want to specify how to represent the entire scope of SPMLv2 (and to address all of its use- cases) RESTfully? Everything that is in SPMLv2 is there for a reason-- usually having to do with the identity-management use-cases with which provisioning-systems deal. Obviously, these identity-management use- cases are more complex than simple user-management, but addressing them in a general way requires more complexity. How much complexity are we willing to tolerate in order to address richer use-cases? Nobody wants to be "Mr. No-Fun." Let me ask this differently: Which of the functions of SPMLv2 do we not need? Or which are needed by everyone, and which are needed only by some? We may be able to keep things really simple if we need few of these. Otherwise, we must describe a general way to do all of them, even if most of the functions are optional. That's not a deal- killer; it just means that our standard may not look as attractively simple. In SPMLv2, the core operations are those participants believed that most everyone would need. Almost everything else that seemed very valuable but not always necessary became a standard capability, each of which is optional. The Capability mechanism is extensible so that others can define and share capabilities not defined in the specification itself. I'll list below some of the things we do in SPML so that people can say which would not be needed in a RESTful binding. This isn't everything, of course, but it's enough to help me survey what a RESTful binding would need to be able to do. 1) ListTargets operation. This is one of the core operations--the bootstrap operation--but you don't need it if you know ahead of time everything that a Provider exposes. It's valuable because it lets a requester discover the available targets (endpoints), and on each the classes of objects that are available to be managed. For each class of object, it also lets you discover which operations are supported and which attributes are exposed. If all you're dealing with is User, this might be overkill. It makes a lot more sense if you're managing Users along with Accounts (and other types of objects) that may exist on any of several targets. The ability to discover schema is particularly valuable with Accounts and other objects, where each type of target (e.g., application) may expose a different attributes with different semantics, and where the set of attributes may sometimes depend on the configuration and/or customization of the application(s) that the Target represents. 2) Async Capability. SPMLv2 supports this optional mechanism because providers sometimes need to obtain approvals before they perform requested operations. More generally, the mechanism supports any operation that the provider must perform asynchronously and does not wish to pretend is synchronous. Within an IDM system, approvals can take an arbitrary length of time--hours or even days. A big, long batch job might take so long to complete that the original session on the transport times out. If you know it could take a long time, it's better to get back an ID that you can use to poll for status or results or to cancel that request. 3) Capability Data. This mechanism allows for add-on behavior (e.g., where a set of operations requires/exposes additional data that is not normally part of the base object as it is persisted in the back-end application that the target represents. These are particularly useful where a third-party component or service contributes additional state about each object. Capability-specific data does not appear by default in a PSO, but SPMLv2 allows a requestor to specify whether the requestor wants it. 4) Batch Capability. Allows one to "boxcar" individual requests. Similarly, provider "boxcars" results/errors. Requester can specify whether to quit at first failure or keep chugging. Requester can specify whether provider must process requests in order (or can process them in parallel). This mechanism is widely useful in business scenarios, especially for synchronization purposes. 5) Bulk Capability. Lets one do a "wild-card" modification or deletion; essentially the operation applies to the set of objects selected by a query. Highly efficient, obviously, where you need to do the same thing to a set of objects that can be selected. 6) Password Capability. Lets an administrator set a password, expire a password, and so forth. 7) Suspend Capability. Lets an administrator enable/disable an object persistently (e.g., for vacation or sabbatical or termination). 8) Updates Capability. Lets you poll for changes. Usually supported by time-stamps, change-log or change-queue. 9) Reference Capability. Allows managements of relationships between objects, particularly where the relationship itself carries information. Examples include a user's membership in an enterprise role, which could carry a start-date and an end-date for that assignment. Another example is a user's relationships to one or more Organizations, e.g., reporting-relationship, dotted-line assignments, administrative responsibility for particular orgs. (Weirder examles inlcude a user's permission or an account's permission to a particular object, which could specify particular actions that are permitted and various conditions under which each action is permitted.) Please share your thoughts on which of these are still important. Gary Cole
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]