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?


Tom - I definitely think the use case approach is best, both for SPML and for SCIM or any other provisioning standardization effort.  I agree with you that we shouldn't go rushing to embrace REST just for the sake of it being something new and shiny, any more than we should be saying "cloud this and cloud that". 

I think there are two reasons to consider REST along with our consideration on how to improve SPML. My first reason is definitely based upon use-cases, and my second reason is purely based on taking a pragmatic approach and saying "why isn't SPML being embraced?" and looking to address that. 

(Paraphrasing from an e-mail I sent to Gary yesterday): Personally I've got a very implementation-specific view on SPML because that's the perspective I come from, where 95% of the work I do consists of implementing and integrating various IDM solutions. I have encountered many clients and scenarios where SPML would have been a useful integration tool, even within an enterprise simply as a lingo franco for enterprise provisioning services between systems. Part of why I go on about simplification is because I want SPML to be as easy as picking up a screwdriver. Today when developers or integrators are faced with simple provisioning scenarios like "I need a service to enable/disable accounts" or password resets, or need to query a user's roles, they aren't picking up SPML and using it for those purposes. 

So my proposal for moving forward really consists of 3 things, all of which are topics which can be lively debated:

1 - simplify SPML as much as possible. Make it extremely easy to use for handling the simplest use cases. Some of this may involve simplifying the profiles, but an important peice this also involves supporting and evangelizing the spec with more reference implementations, samples, etc.

2 - add more features to SPML that address specific use cases - we've itemized many of these in our existing use case work. My ideas here are to focus on specific real-world use cases like password management, user role management, and adding specific typed (but optional!) metadata to SPML operations to support audit & compliance tools

3 - create a lightweight REST-based interface for SPML where the REST aspects (URLs, HTTP verbs etc) can take the burden off of the request & response payloads. I think tools like JAX-RS and JAXB can help simplify the requests and also allow the responses to be transformed to for example XML or JSON. How much of this type of thinking needs to be in the core SPML spec vs reference implementations is definitely an important discussion we should take, but my main point is that the SPML spec should not prevent these types of implementations.

Looking forward to discussing these topics with everyone on the call today.

Best regards,

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: Smith, Thomas C. [mailto:Tom.Smith@jhuapl.edu] 
Sent: Wednesday, May 11, 2011 12:22 PM
To: OASIS PSTC
Subject: RE: [provision] Re: RESTful SPML: Scope of use-cases to address?

The problem that I have with this is that the operational/business needs and priorities provide the use-case context, not technologies. Let's define the problem before creating the solution. I recognize that this approach is very "Ivory Tower" and that we need to address SCIM as a practical alternative to SPML. So to that end, why does SCIM exist? The complaints that I've seen about SPML focus on its total lack of momentum. This may be because it's too complicated, not RESTful, not the latest bright new shiny object, etc., but the hype is that SPML is dead because of a lack of vendor support and that's the kiss of death for a standard. However, companies still have provisioning needs, so now we have SCIM - yet another mechanism for CRUD. Are these capabilities meeting the provisioning needs? Since we don't have is a clear description of these provisioning needs, we really cannot say. I suggest that chasing after a RESTful SPML does not address the fundamental issue of "What's the provisioning problem?", and that this exercise actually fosters a lack of momentum. I think it would be very helpful to be able to cite the use-cases that SPML and SCIM handle as well as the ones they do not. Therefore I see the PSTC's provisioning use-cases that are under development as a valuable contribution to the community and I recommend that we continue down that path striving to be as implementation agnostic as possible. Yes, let's not be moths around the new shiny RESTful object.

The justification of each KEEP capability listed below enumerates some (if not most) of the needs. This should be done for the LOSE and UNSURE capabilities too and then all of these should to be flushed out and presented as use-cases. There's also some ideas in the Gartner/Burton "Provisioning's Role in the Next-Generation IdM Architecture", Lori Rowland, 7-6-10 article.

-tom 


-----Original Message-----
From: Gary Cole [mailto:gary.cole@oracle.com] 
Sent: Monday, May 09, 2011 2:58 PM
To: OASIS PSTC
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


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


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