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?


Hi Gary - I added my comments inline below. 

Richard Sand | CEO
239 Kings Highway East | Haddonfield | New Jersey 08033 | USA
Mobile: +1 267 984 3651| Office: +1 856 795 1722| Fax: +1 856 795 1733




-----Original Message-----
From: Gary Cole [mailto:gary.cole@oracle.com] 
Sent: Monday, May 09, 2011 2:07 PM
To: OASIS PSTC
Subject: [provision] Re: RESTful SPML: Scope of use-cases to address?

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.

RS: Agreed. I do think this should be optional and not mandatory, even though returning an empty list is trivial.

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.

RS: Strongly agree here. I think we should have a robust set of use cases here because password management as well as account enabled/disabled state are in my opinion the two biggest use cases driving provisioning.

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.

RS: Agree as stated above.

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

RS: Agree. I definitely think this capability is important in a SOAP-based model and I don't think it's something SPML should drop, but for a lighter weight REST model I agree it isn't necessary.

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).

RS: Agree.

Batch Capability (#4) is not needed.  A RESTful is primarily  
synchronous, and the client/requester can run its own batches if it  
wishes.

RS: Agree

Bulk Capability (#5) is not needed.  A client/requester can search and  
then invoke HTTP operations on each item in the search-result.

RS: Agree

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.

RS: Agree and don't think its important for the 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]