[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Re: RESTful SPML: Scope of use-cases to address?
Kent Spaulding pointed out that I did not mention the Search Capability. We need search, of course. I would suggest two flavors of search: 1) Simple search, of the form "<attr>=<value> [, <attr>=<value> ]", in which conditions are implicitly ANDed. 2) Advanced search, of the form "query=<encoded-string-format-ldap- search-filter'", which could support nested logical operators AND, OR and NOT. Gary On May 9, 2011, at 1:06 PM, Gary Cole wrote: > Just in case anyone is shy about saying that a RESTful provider > doesn't need something that SPMLv2 has, let me kick this off by > offering a few suggestions: > > KEEP: > > ListTargets (#1) is still needed. We need to manage more than > Users, and we need to manage things on multiple Targets. Being able > to discover the schema provides valuable metadata and offers an > alternative to hard-coding. > > Password Capability (#6) is still valuable. In fact, we want also: > end-user password changes, end-user profile-management, Forgot My > Password and Forgot My LoginName. > > Suspend Capability (#7) is still valuable. Many enterprises disable > users or accounts (rather than hard-deleting them) until audit-log > requirements have passed and the data objects have been archived > appropriately. > > Reference Capability (#9) is valuable for identity-management > systems, so I think we need this flexibility (and so will the cloud > in the long term). > > > LOSE: > > Async Capability (#2) is *not* needed. A RESTful provider is > primarily synchronous, and > > Capability Data (#3) is not needed (or seems low-priority). If > these data-items are really important, the provider can include them > in the schema for each object-type (or can represent each capability- > specific set as some kind of auxiliary-class). > > Batch Capability (#4) is not needed. A RESTful is primarily > synchronous, and the client/requester can run its own batches if it > wishes. > > Bulk Capability (#5) is not needed. A client/requester can search > and then invoke HTTP operations on each item in the search-result. > > > UNSURE: > > Updates Capability (#8) is very cool, but feasible to support only > when the back-end offers some appropriate mechanism. Not > necessarily easy or natural to expose in a RESTful representation. > > > On May 9, 2011, at 12:08 PM, Gary Cole wrote: > >> 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 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]