[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]