RE: [provision] Community input on Future of Standards-BasedProvisioning and SPML

[Hal Lockhart <hal.lockhart@oracle.com>]

Yes, I am sorry it has been a long time and I have forgotten the terminology.

Simplifying the provider is I believe what was intended. I am not expressing my opinion, BTW, simply trying to interpret the results from the SIG. The first 4 of the 6 bullets seem to be aimed at simplifying implementations. The point about conformance may not be something the TC can do anything about. The one about a schema is confusing, I thought SPML had a schema. Are they talking about schemas for the actual provisioning data?

Hal


> -----Original Message-----
> From: Gary Cole 
> Sent: Monday, August 30, 2010 1:13 PM
> To: Hal Lockhart
> Cc: John, Anil; provision@lists.oasis-open.org; Mark Diodati
> Subject: Re: [provision] Community input on Future of Standards-Based
> Provisioning and SPML
> 
> 
> I think the terminology or the diagram may be confusing.  A 
> requestor  
> (RA) requests operations of a provider (PSP).  The provider manages  
> identities (PSOs) on at least one target application (PST).  The PST  
> is the actual target application--e.g., an instance of PeopleSoft or  
> RACF or Active Directory--but is not at a part of the 
> implementation,  
> so we cannot simplify the PST.  We can simplify the requestor or  
> provider--usually the provider.
> 
> The simplest provider manages identities on a single target.  A more  
> complex provider may manage identities on several targets, in which  
> case the provider's listTargetsResponse should list the available  
> targets and describe the schema for each target.
> 
> If we interpret the diagram as if each of these entities were code  
> that we write (as it sounds like you have), then the PST 
> would be the  
> component that is specific to each type of target 
> application.  In the  
> original terminology, that's still a provider (PSP), perhaps front- 
> ended by another PSP that is visible to remote requestors.
> 
> Terminology aside, then, you think the connector problem is  
> simplifying the development and testing (and perhaps 
> certification) of  
> a *provider* for each type of target application?
> 
> Gary
> 
> On Aug 30, 2010, at 11:56 AM, Hal Lockhart wrote:
> 
> > Reading between the lines of Mark's blog, I think what is meant  
> > about the connector problem is that since in a typical scenario,  
> > there is one PSP provisioning multiple PSTs. Therefore if the PSTs  
> > can be made as simple as possible, with the PSP doing most of the  
> > work, the overall complexity of engineering a solution will be  
> > minimized.
> >
> > Is that approximately correct, Anil?
> >
> > Hal
> >
> >> -----Original Message-----
> >> From: Gary Cole
> >> Sent: Monday, August 30, 2010 12:34 PM
> >> To: John, Anil
> >> Cc: provision@lists.oasis-open.org; Mark Diodati
> >> Subject: Re: [provision] Community input on Future of 
> Standards-Based
> >> Provisioning and SPML
> >>
> >>
> >> Thank you for posting this, John. This statement by the SPML SIG
> >> certainly helps to frame our discussion.  In order to advance that
> >> discussion, it would be helpful to have a description of the
> >> "connector problem" and of the use-provisioning use-cases 
> for cloud-
> >> based applications.  Would this SIG (or its members) be able to
> >> provide this kind of direction?
> >>
> >> I like the idea of a simple profile, and I look forward to the
> >> development of a consensus.  Perhaps the concrete use-cases for
> >> provisioning to cloud-based applications will help to focus this
> >> profile and to limit some of the flexibility that
> >> participants in the
> >> specification of SPMLv2 and its DSML and XSD profiles required.  To
> >> that end, I offer a few comments and ask a few questions 
> intended to
> >> clarify the "Back to Basics" description of the simple
> >> profile (inline
> >> below).
> >>
> >> On Aug 25, 2010, at 3:31 PM, John, Anil wrote:
> >>
> >>> All,
> >>>
> >>> I am sure that folks here have been tracking the
> >> conversation around
> >>> Standards based provisioning and SPML that was initiated by Mark
> >>> Diodati of Gartner/Burton Group and since then has continued both
> >>> online and at the SPML SIG that was held at the the Gartner/Burton
> >>> Group Catalyst Conference last month.  Mark recently posted the
> >>> notes of that meeting on his Gartner blog
> >> (http://blogs.gartner.com/mark-diodati/
> >>> ) and the consensus agreement of the participants in the SIG (Full
> >>> Disclosure: I was a participant in the SIG)
> >>>
> >>> I wanted to make sure that it was provided to the SPML TC as input
> >>> into the TC Charter discussions we will soon be having (Full text
> >>> below as well as link to original entry)
> >>>
> >>> Regards,
> >>>
> >>> - Anil
> >>>
> >>> :-
> >>> :- Anil John
> >>> :- Johns Hopkins University - APL
> >>> :- http://www.jhuapl.edu
> >>> :- +1 240.228.0612
> >>> :-
> >>> :- E-Mail Response Time: 24 hrs
> >>>
> >>> ========================
> >>>
> >>> Consensus on the Future of Standards-Based Provisioning and SPML
> >>>
> >> http://blogs.gartner.com/mark-diodati/2010/08/20/consensus-on-
> >> the-future-of-standards-based-provisioning-and-spml
> >>> by Mark Diodati  |  August 20, 2010
> >>>
> >>> I had the honor of facilitating the Standards-Based Provisioning
> >>> Special Interest Group at this year’s Catalyst conference. The
> >>> participants believe that standards-based provisioning is at a
> >>> crossroads and wish to publish the following statement. The
> >>> statement is based upon our conversation; all of the participants
> >>> have reviewed it.  I hope that the perspectives of these industry
> >>> luminaries push the industry (and the especially the
> >> newly-reformed
> >>> OASIS Provisioning Services Technical Committee) towards a viable
> >>> provisioning standard.
> >>>
> >>> ——————————————————————————————————————-
> >>>
> >>> Moving Forward on Standards-Based Provisioning
> >>> On Tuesday, July 27 a group met at the annual Burton Group North
> >>> America Conference in San Diego to discuss the future of
> >>> standardized provisioning and Service Provisioning Markup Language
> >>> (SPML). The group readily achieved a consensus about two
> >> things: the
> >>> need for standards-based provisioning and the qualities
> >> required for
> >>> successful provisioning standard. The following people
> >> participated
> >>> in the special interest group (SIG):
> >>>
> >>> Abdullah Haydar (Open Dealer Exchange)
> >>> Andrew Ferguson (e2B2Bcom)
> >>> Anil John (Johns Hopkins)
> >>> Ash Motiwala (Identropy)
> >>> Chuck Mortimore (salesforce.com)
> >>> Jacob Farmer (Indiana University)
> >>> Jonathan Sander (Quest)
> >>> Mat Hamlin (SailPoint)
> >>> Nick Nikols (Novell)
> >>> Nishant Kaushik (Oracle)
> >>> Steven Legg (e2B2Bcom)
> >>> Tony Goulding (CA)
> >>>
> >>> The participants have firsthand experience with the
> >> difficulties of
> >>> proprietary provisioning from the perspective of both
> >> vendor and end-
> >>> user organizations. The SIG meeting was particularly
> >> timely, as the
> >>> Organization for the Advancement of Structured Information
> >> Standards
> >>> (OASIS) is evaluating the need for an SPML v3 standard.
> >>> Additionally, the SaaS market is at a critical juncture as vendors
> >>> look for standards-based solutions to the provisioning problem.
> >>>
> >>> SPML v2
> >>>
> >>> The second iteration of the SPML standard was approved in
> >> the spring
> >>> of 2006 and included additional capabilities and
> >> operational modes.
> >>> In trying to address every possible use case, interoperable
> >>> provisioning services leveraging the SPML v2 standard became
> >>> impractical. Since the approval, few (if any) conformant
> >>> implementations exist due to the complexity of the v2 standard.
> >>> Additionally, vendor participation in the OASIS Provisioning
> >>> Services Technical Committee (PSTC) has been nearly non-existent
> >>> since v2 was approved.
> >>>
> >>> Organizations wishing to use SPML must write provisioning services
> >>> specifically for each vendor’s SPML implementation (if the vendor
> >>> supports SPML at all). The difficulty in building a single,
> >>> interoperable provisioning service has made the adoption of
> >> SPML by
> >>> application developers a non-starter. Without adoption by
> >> enterprise
> >>> and cloud application developers, SPML will not be adopted. In
> >>> conclusion, the SPML v2 standard is broken.
> >>>
> >>> Back to Basics
> >>>
> >>> The next iteration of SPML should focus on solving “the connector
> >>> problem” and provisioning use cases for cloud-based applications.
> >>> That is, the next version of SPML should readily enable the
> >>> development of simple, standards-conformant provisioning services
> >>> for both enterprise and cloud applications.
> >>>
> >>> The participants agree that a standards-based provisioning
> >> protocol
> >>> is needed, and all concluded (except Chuck Mortimore) that it is
> >>> best to evolve the SPML standard rather than introduce a new one
> >>> (salesforce.com has not yet arrived at this conclusion). The next
> >>> iteration of SPML needs to become simpler. It must support
> >> a simple
> >>> use case for conformant, standards-based provisioning services.
> >>> Additionally, the SPML standard is too imbalanced; it places too
> >>> much burden on target applications. The participants assert
> >> that the
> >>> next version of SPML must possess a “simple” profile for to be
> >>> successful. The simple profile should include the following
> >> qualities:
> >>>
> >>> * Provide basic create, read, update and delete (CRUD) operations.
> >>
> >> I assume this is a statement of required scope for the simple
> >> profile.  Aside from listTargets, these are the only 
> operations that
> >> SPMLv2 requires.
> >>
> >>> * Focus on the default use case of a single provisioning service
> >>> point (PSP) and provisioning service target (PST). This use
> >> case is
> >>> the default one for application developers and end-user
> >> organizations.
> >>
> >> SPMLv2 optimizes the use-case of a single target by allowing the
> >> 'targetId' parameter to be omitted when a provider exposes only a
> >> single target.  The listTargetsResponse for a minimal
> >> provider (or for
> >> a provider whose capabilities are well-known to the
> >> requestor) can be
> >> very terse.
> >>
> >> In what other ways should the simple profile focus on this
> >> default use-
> >> case?
> >>
> >>> * Eliminate transactional auditing requirements. In
> >> particular, the
> >>> Updates capability places an impractical data retention and
> >>> performance burden on the application.
> >>
> >> The Updates Capability is optional.  No provider is required to
> >> support this capability.
> >>
> >>> * Support a simple search mechanism. The current search mechanism
> >>> can create nearly infinite search parameters across all known user
> >>> attributes, which places an undue burden on the application.
> >>
> >> The design point for the DSML Profile was LDAP search.  The design
> >> point for the XSD Profile was XPath search.  What would be
> >> the design
> >> point for search in the simple profile?
> >>
> >> Is the goal to improve the convenience of simple searches for the
> >> requestor, or to simplify the search function that a provider must
> >> support?  If the goal is to simplify the search function that a
> >> provider MUST support, would conformance with the simple
> >> profile also
> >> restrict the search function that a provider MAY support?
> >>
> >>> * Enforce conformance. Vendor’s products must undergo conformance
> >>> testing prove interoperability. Conformance likely requires a
> >>> reference implementation.
> >>
> >> This seems like an excellent suggestion.  If we can define (and can
> >> agree to) a common set of behavior expectations, this 
> should greatly
> >> simplify the process of developing and certifying a 
> provider.  Would
> >> we want to do something similar for requesters?
> >>
> >>> * Provide an optional, standard schema. An optional
> >> standard schema
> >>> (like LDAP’s inetorgperson) provides a potential schema for
> >>> immediate interoperability with other applications.
> >>
> >> This sounds highly desirable.  If participants can define (and can
> >> agree to) a common set of attributes (and potentially 
> common object-
> >> classes), this should greatly facilitate interoperability.
> >>
> >> The first questions that occur to me are: Would this 
> standard schema
> >> need to be extensible?  Would all attributes be required?
> >> Would each
> >> predefined attributes imply a certain contract that the conformance
> >> tests could exercise?
> >>
> >>>
> >>> The Path Ahead
> >>>
> >>> It is up to vendor and end-user organizations to move the SPML
> >>> standard forward so that the industry can begin to build
> >>> interoperable provisioning services. If you are interested in
> >>> influencing the direction of standards-based provisioning
> >> and SPML,
> >>> please consider participating in the OASIS PSTC.
> >>>
> >>>
> >>>
> >> 
> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> 
>