[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] What exactly do we mean by provisioning?
To add my $0.02 in the discussion further define
what provisioning may be, I wanted to restate three other versions which were discussed
previously before the PSTC became official.
Any comments, suggestions, dislikes about the ones below: 1) Provisioning - The
self-service management of user identity data (e.g., identity, role) in a centralized
manner to resources across an enterprise and extended enterprise. The resources
may have attributes mapped across to multiple applications. The attributes to these
resources may consist of the following actions: Add, Modify, Delete, Suspend, Restore, Search, Notify, etc... 2) Provisioning - The process of managing attributes within the
scope of a define business process or interaction. Provisioning a service may involve the creation, modification, deletion,
suspension, restoration of a defined set of attributes for a user, group of
users or system 3) Provisioning -
The process of managing attributes and accounts within the scope of a defined
business process or interaction.
Provisioning an account or service may involve the
creation, modification, deletion, suspension, restoration of a defined set or
accounts or attributes. About Darran’s comments: 1
– The attributes of the “provisioned to” thing could be
dynamically queried so are therefore less critical to scope “This needs to be discussed,
defining attributes to objects particularly ones being queried by different
systems may be a sensitive subject.
Items within the scope need to be further discussed. Please define and/or ‘dynamically
queried.’” 2
– However, I agree we need to scope the term to better facilitate
understanding of the work at hand “Agreed,
as discussed earlier we just define the main scope and working groups may
branch off of it to reach this intended goal” 3 -
I’d rather avoid eProvisioning (a bit close to some existing products in
this space) “I
agree” 4
– How about eService Provisioning? “Sounds
too much like provisioning web services” 5
– We should deliberately run a loose boundary around the “provision
to” list/terms, whilst at the same time avoiding “Thus far we have: 1) electronic services; and 2) resources
across an enterprise and extended enterprise” I agree with “identity” as
well as the preferred “prefix.” - -----Original Message----- 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 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. - [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