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