[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] What exactly do we mean by provisioning?
I think what we are trying to get to
here is wording that includes the ability to pass requests to a provisioning
service that itself may be driving a “non-digital” provisioning
process. To
explain... abcProvisioing Inc
provides a PSML compliant provisioning server. Behind it’s
PSML interface is a cross-system provisioning server, managing a range of
directories, applications and servers PLUS (to use a simple understandable
example) a non-digital cell-phone request “resource”. The former are the well understood
resources – account/security/attribute oriented things that we all seem
to agree are in scope. The latter is really just an encapsulated workflow
process that when provisioned to results in a managed request/response protocol
to some down stream service component (deliberately vague and clearly out of
scope for PSML). The abcProvisioning service may even
group all these resource elements into an arbitrary collection suitable or
useful for general management purposes or as part of some internal role based
allocation mechanism. This makes most sense when you consider provisioning
a new user at abcSupplyCo. The new guy needs a directory account, a
couple of UNIX accounts, an NT and exchange account, some entries in some RDBMS
tables somewhere for some C/S apps AND a cell phone request sent to cracklyWirelessCo via a simple secure email interface. The user of the PSML service goes
through a trust establishment, service query and required attributes exchange with
the provisioning service. It then
send off all the required identity and security attributes along with an <cell_phone plan=’gold’ phone=’simple’
services=’all’/> element. The definition of the required data to
provision these things would be the responsibility of the provisioning service
to “define” and ship back to the requester in some form of query
vocabulary. So I guess what I’m
saying is: 1 – The attributes of the “provisioned
to” thing could be dynamically queried so are therefore less critical to scope 2 – However, I agree we need to
scope the term to better facilitate understanding of the work at hand 3 - I’d rather avoid eProvisioning (a bit close to some existing products in
this space) 4 – How about eService Provisioning? 5 – We should deliberately run a
loose boundary around the “provision to” list/terms, whilst at the
same time avoiding Edwards sea boiling. Darran Rolls -----Original Message----- I don't have a problem
with trying to narrow the scope. However, I think we need to think beyond
people. For example, I can see other types of objects (e.g. workstations,
applications) being "provisioned" (granted access to IT resources
& services) in the future, especially if we are using provisioning as a
means of managing RBAC. This is a significant point that has been made by
several NAC members over the past year - that we should seek to avoid being "person-centric"
when defining requirements and designing solutions. Therefore, I would
suggest that Hal's first idea is the "best" choice here. Think of all
the types of objects (entries) that we might want to store in directories and
manage access to resources and services for (I can certainly accept an IT focus
for now, lest we end up in an ocean-boiling exercise), and focus on how to
encode the schema for these so that the various provisioning systems and the
provisioned (target) systems can easily communicate amongst each other.
If
"eProvisioning" isn't owned by somebody, that might be the best term
to use. Otherwise, I would prefer something like "IT Services
Provisioning" or "ProvisionIT" which the TC could define as it
wishes. -Ed Truitt [snipped for brevity]
The ADPr site offers this: "eProvisioning refers
to automating the process of systematically providing resources and services,
according to business requirements." However all the examples they cite
revolve around a person. So I guess the choice boils do to pretty much two
ideas: 1. We need to limit scope in some way if we hope to
accomplish anything. Hal |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC