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


Subject: RE: [provision] Scope of SPML -- Identities and Resources


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 


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


Powered by eList eXpress LLC