Re: [provision] Scope of SPML -- Identities and Resources

[jbohren@opennetwork.com (Jeff Bohren)]

One idea I brought up in XRPM was to emulate the SNMP approach of defininge
extensible, standard schema's for common  classes of targets. I'm not
suggested we use ASN.1, but what I am suggesting is that after defining a
mechanism for defining schemas in general, we define a set of predefined
schemas for commonly provisioned services, or using Darran's proposed
terminology, Provisioning Service Target (PST).

For instance, in SNMP, all agents should conform to the core schema MIB-II,
but all agents that are embedded in printers should additionaly conform to
the standard Printer MIB. Likewise all routers should conform to the Router
MIB. This way any management SW written to the Printer MIB could manage, in
some fashion, any printer that also adhered to the Printer MIB. Of course
all vendors can, and do, extend their schemas to cover features they view as
important, but are not covered in the standard schema.

Note that in Anand's e-mail about the Jamcraker experience with
provisioning, he naturally groups the PST's into catagories (e.g.
Directories, OS's, Networks, Security, etc.). I think that this is a logical
thing to do, and will enhance interoperability.

Obviously a complete set of standard schemas can not be accomplished in the
time frame of the proposed charter. What we could do is to define a schema
definition mechanism and publish drafts for one or two standard schemas.

Jeff Bohren

Darran Rolls wrote:

> An assumption
> --------------
> As a pre-cursor to my comments here, I should state a working assumption
> that I personally have in mind that we need to discuss (I have several
> other relating to identity scope etc that I will fwd in a separate
> mail).  My assumption is that the PSTC is not setting out to define a
> DTD/schema library for every resource/service/thingy we envisage being
> supported by a SPML compliant provisioning service.  It would be the job
> of the queried SPML service to respond with an artifact that detailed
> the attributes required to complete a request. This process would look
> something like this:
>
> A queries B for the required schema for thing X
> B send an attribute/type list to A to provision a new instance of X
> A makes up a suitable SPML artifact from this and sends it back to B
> B does it's thing with the artifact and communicates the results back to
> A
>
> I do believe we will need to define some notion of an identity schema as
> this will be required in many cases for updates and initial
> queries/requests that relate to some already established primary
> identifier.
>
> Comment on the thread
> ---------------------
> I believe my assumption above make it less relevant the list of things
> we have to say are in scope.  At the OMG/OASIS interoperability and
> modeling summit this week, I had the opportunity to ask someone what
> they would consider in scope for provisioning. Interestingly, he took
> provisioning to include distributing software and applications! Having
> worked on a software distribution product in a previous life, the
> implications his answer had on scope and complexity at first horrified
> me.  However, once I picked myself up off the floor and thought about
> it, I came to the conclusion that yes, maybe it could considered in
> scope.  After all, in the context of my initial assumption does it
> matter what B says it wants so long as A can supply it?.
>
> This position puts SPML as the structure and framework for the
> request/response flow not the prescription of the schemas that can flow
> over it. This enables the desirable things re RBAC that Edward mentions
> but does not sign us up for a 4 year schema design course.
>
> I'm at Disney World Orlando right now so telling me I'm on another
> planet on this would be somewhere near the truth ;-)
>
> --------------------------------------------------------
> Darran Rolls                      http://www.waveset.com
> Waveset Technologies Inc          drolls@waveset.com
> (512) 657 8360                    PGP  0x8AC67C6F
> --------------------------------------------------------
>
>
>
> -----Original Message-----
> From: Truitt, Edward D. (OSED) [mailto:OSED@chevrontexaco.com]
> Sent: Thursday, December 06, 2001 5:15 PM
> To: 'provision@lists.oasis-open.org'
> Subject: RE: [provision] Scope of SPML -- Identities and Resources
>
> My comments, below.
>
> Edward D. (Ed) Truitt
> Systems Analyst, Directory Services
> Global Infrastructure Delivery / Global IT Delivery
> ChevronTexaco  Information Technology Company
> Ph# +1 281.596-3246 Fax# +1 281.596-2714
> Cell phone / Pager # +1 832.443-7283
> "Got IT?"
>
> -----Original Message-----
> From: Ranthidevan, Anand [mailto:aranthidevan@jamcracker.com]
> Sent: Thursday, December 06, 2001 4:13 PM
> To: provision@lists.oasis-open.org
> Subject: [provision] Scope of SPML -- Identities and Resources
>
> [snip for brevity]
> IDENTITIES: As *who* requires to be added, modified, or deleted. This
> shouldn't be limited to just Users, as that's too narrow. The main ones
> we've come across and have implemented (albeit without the benefit of a
> standard) are:
> 1. Systems
> 2. Companies
> 3. Company Structures -- like Divisions, Departments, Cost Centers,
> Locations, Employee Types, and so on.
> 4. Users
> 5. User Roles
>
> [Truitt, Edward D. sez] While this is a good list, I still feel strongly
> that we need to include other inanimate IT entities in the list - like
> PC and server systems, switches, routers, PBXes, applications...  The
> reason is that, while may of us think of these as "resources" or
> "services" to be provisioned, in a real sense they can take on the role
> of "provisionee" - for example, you could use a provisioning system to
> connect an application to a middleware bus (e.g. TIBCO), or
> to "provision" a certain level of network service (QoS) to a web server,
> or to "provision" a PC to the Active Directory (create/manage its
> computer account).  This could allow us to extend RBAC into places we
> are just beginning to think of (example:  I may want to prohibit any
> system from running the IIS service, unless it is in a role that
> requires it, and unless the primary user for that system understands
> this and is aware of the risks involved.  So, I define what "roles" a
> machine must occupy in order to be authorized to start the IIS service,
> and "provision" the machine to that service via a provisioning flow -
> for example, placing the machine into a specific group, or OU within the
> directory.)
>
>  [More snippage for brevity]
>
> To make this more concrete, I can go ahead and put together some general
> business scenarios and use cases.  Would that work for everyone?  Should
> I post them to this list?
>
> [Truitt, Edward D. (OSED) sez] Works for me!
>
> -Anand
> [Anand Ranthidevan]
> Product Manager - Jamcracker Platform
> aranthidevan@jamcracker.com
> http://www.jamcracker.com
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Jeff bohren
Product Architect
OpenNetwork Techologies
jbohren@opennetwork.com
(727) 561-9500x219