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] What exactly do we mean by provisioning?


 
Identity in the context of provisioning should mean something that uniquely identifies a party (user or system) across multiple provisioning systems. Suppose we have one provisioning system that can provision cell phones and another that can provisision access to a web service. Being a "Gold Customer" may mean something to the fomer but not the latter. "Gold Customer" is an attribute of the party that has a specific identity but is not part of that identity itself.

Note also the attributes such as "Gold Customer" may change value based upon other dynamic attributes of the party (e.g. miles flow, dollars spent, etc). As these attribute change in value that should not affect the identity of the party, but could affect  the resources that are provisioned for that party.

Jeff Bohren

Hal Lockhart wrote:

 
 

> I like the idea of using tying "Identity" to "Provisioning"
> to describe what we are doing, but we have to be careful. We
> should not give the impressiong that the focus is to manage
> the identity itself.

I think we are. I believe identity is the sum of the attributes of the entity being identified. If I say you are a Gold Customer, I am managing your identity. Perhaps you meant we are not managing the Proof of Identity (Authentication inputs). However, I suspect that some people will want to ship this stuff around as well, although we should certainly avoid the unnecessary duplication of existing protocols for Authentication, Certificate Management, etc.

Hal

>Unfortunately, "Identity-Related
> Provisioning" is likely to cause that exact sort of
> confusion. The best term I can come up with is:
>     Resource to Identity Provisioning
> Which is descriptive but probably to long.
> I think we should stick with "Provisioning" for now and tie
> it to a definition of what it means.
> Jeff B.
> Darran Rolls wrote:
> 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
>
> Waveset Technologies
> MSIM  drolls_waveset@hotmail.com
> AIM    drollswaveset
> YIM    drolls_waveset
> http://www.waveset.com/
> drolls@waveset.com
>
> -----Original Message-----
>
> From: Truitt, Edward D. (OSED) [mailto:OSED@chevrontexaco.com]
> Sent: Tuesday, November 27, 2001 4:56 PM
> To: 'provision@lists.oasis-open.org'
> Subject: RE: [provision] What exactly do we mean by provisioning?
> 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
> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Tuesday, November 27, 2001 2:51 PM
> To: provision@lists.oasis-open.org
> Subject: [provision] What exactly do we mean by provisioning?
>
> It is time to be more precise about the charter of this
> group. In particular I am concerned about the meaning of the
> unmodified word "Provisioning" which I believe may mean
> different things to different people.
> [snipped for brevity]
> The second is broader than the first, but both are much
> narrower than the meaning above in that they revolve around
> the concept of "user" and therefore identity. For example, if
> a web hosting company sets up a virtual server for a new
> customer, this would be included in the broader meaning, but
> not the narower one. Thumbing through the materials from the
> XRPM meeting, it seems to me that most of the people present
> had in mind the narrower meaning. In particular, Phil called
> for a standardized way to encode the identity schema.
> 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. Eveything you do in responce to an order for service.
> 2. Everything you do to provide service for a person.
> My position is that I don't feel strongly about what scope is
> chosen as long as it is made explicit. I offer the following
> observations:
> 1. We need to limit scope in some way if we hope to
> accomplish anything.
> 2. If the scope is limited to "identity-related"
> considerations, we might want to qualify the term
> provisioning with an adjective, since there are a large
> number of organizations that use the term in a broader sense
> and are likely to misinterpret our use. Possibilities
> include: User Provisioning, User Service Provisioning,
> Identity-related Provisioning.
> Hal
> --
> Jeff bohren
> Product Architect
> OpenNetwork Techologies
> jbohren@opennetwork.com
> (727) 561-9500x219
>
>

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



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


Powered by eList eXpress LLC