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?


Title: RE: [provision] What exactly do we mean by provisioning?

OK, you have now brought up the reason I raised the issue in the first place. Is all the information we exchange going to be associated with a "identity" which corresponds to a System Entity, or are there other classes of data?

[SAML definition of System Entity: An active element of a computer/network system--e.g., an automated process or set of processes, a subsystem, a person or group of persons--that incorporates a distinct set of functionality.]

As far as a universal identifier, you are bucking expert opinion in the security community, which holds that principals can only be identified by a domain-specific identifier combined with security domain. That is not to say you can not make the security domain very large, but you cannot make it universal.

Personally I had been assuming that PSML would specify (or assume) some means for a number of cooperating parties to agree on a common specifier.

Hal

> -----Original Message-----
> From: jbohren@opennetwork.com [mailto:jbohren@opennetwork.com]
> Sent: Wednesday, November 28, 2001 12:39 PM
> Cc: provision@lists.oasis-open.org
> 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