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] 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]