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] Community input on Future of Standards-BasedProvisioning and SPML


Gary,

It was understood that the Updates Capability is optional, but the Synchronization use case that is possible with Updates came up during the SIG, which is where that comment came from.

Regards,

- Anil

> -----Original Message-----
> From: Gary Cole [mailto:gary.cole@oracle.com]
> Sent: Monday, August 30, 2010 2:01 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
>
> The OpenSPML Toolkit simplifies the implementation of a provider--at
> least for the DSML profile.
>
> They seem to misunderstand--or perhaps I misunderstand--as when they
> imply that the Updates Capability is required.  That's just wrong.
>
> SPML does not specify a schema.  (That's work we intended to do after
> publishing SPMLv2, but dropped.)  The standard (and each profile) says
> how a provider exposes the schema of a target, but these specify only
> meta-data.
>
> On Aug 30, 2010, at 12:56 PM, Hal Lockhart wrote:
>
> > 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
> >>>>
> >>>>
> >>
> >>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]