[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
Gary Cole is working on the minutes, again... The next meeting is Monday 9/13 at 2:00pm Eastern time. Before that time, Richard Sand promised to publish a poll regarding meeting times (perhaps on Doodle) so we can all find the most convenient time for the meetings after that. --Kent On Aug 30, 2010, at 2:09 PM, Hal Lockhart wrote: > My apologies to all. I misread the announcement and thought it was at 5:00 ET. > > Do we have a new meeting time? Will someone publish minutes? > > Hal > >> -----Original Message----- >> From: John, Anil [mailto:Anil.John@jhuapl.edu] >> Sent: Monday, August 30, 2010 2:13 PM >> To: Hal Lockhart; Gary Cole >> Cc: provision@lists.oasis-open.org; Mark Diodati >> (Mark.Diodati@gartner.com) >> Subject: RE: [provision] Community input on Future of Standards-Based >> Provisioning and SPML >> >> >> Gary & Hal, >> >> Re: "Connector problem" >> >> This is meant to speak at the higher level that current >> provisioning systems require custom connectors (that are >> proprietary) to connect to existing systems and that SPML is >> seen as the way to get away from that arena. >> >> Re: "Optional, Standard Schema" >> >> Think analog to inetOrgPerson (Payload) for provisioning use, >> not about the XSDs defined by as part of the SPML protocol (Plumbing). >> >> Regards, >> >> - Anil >> >>> -----Original Message----- >>> From: Hal Lockhart [mailto:hal.lockhart@oracle.com] >>> Sent: Monday, August 30, 2010 1:57 PM >>> To: Gary Cole >>> Cc: John, Anil; provision@lists.oasis-open.org; Mark Diodati >>> Subject: RE: [provision] Community input on Future of >> Standards-Based >>> Provisioning and SPML >>> >>> 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 >>>>>> >>>>>> >>>> >>>> >> >> --------------------------------------------------------------------- >> 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]