[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