[provision] Identity Scope & Authority

[Darran Rolls <Darran.Rolls@waveset.com>]

I wanted to come back to a discussion in an earlier thread and raise it
to it's own new thread.  It relates to the scope of an identity as
discussed by Hal and Jeff (included below).

Firstly I'd like to suggest some possible terms for adoption by the
committee as we begin to discuss these issues. I have no great binding
to the terms or acronyms as the nature of each is distinct and I believe
required so we can easily change them if required.

Terms
=====
1) Provisioning service (PS)
Any system entity that supports the receipt and processing of SPML
artifacts

2) Provisioning Service Point (PSP)
Reference to a given Provisioning Service

3) Provisioning Service Target (PST)
A system entity managed by a PSP.  This is often referred to as a
resource in the user provisioning world.  Example PST's are directories,
NIS instances, NT domains, individual machines, applications, appliances
or any provisioning target.

4) Provisioning Service Requestor (PSR)
A system entity making SPML requests to a PSP.

Identity Scope Assumptions
==========================
Before considering the following, please look at the attached ppt.  It
includes a summary of the points and a high-level representation of it's
meaning.

1) Each PSP would be responsible for its own identity scope.  On the
basis that cooperating PSP's could agree on primary identifiers as part
of the provisioning request flow, identities could be synchronized
across PSP's but fundamentally, authority over the identity would be
limited to each PSP.

2) A PSP can be responsible for multiple PST's and any given PST can be
responsible for (or have authority over) over its own identity domain.

3) A PSP would provide a unique queryable namespace for each of the
PST's it was responsible for.

4) PSP's would be able to aggregate multiple PST's to form a single SPML
addressable/provisionable PST object. An aggregated PST would look and
function just likes any other PST (concisely it would not be
distinguishable from a non-aggregated PST outside of the union of the
required attributes).  Further more, it would be the job of the PSP to
handle identity and general provisioning from the aggregation out to its
wider collection of PST's. To be clear here, I am not suggesting that
any notion of the down-stream handling of this type of aggregation be
considered in scope for SPML.

Comments?

--------------------------------------------------------
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
(512) 657 8360                    PGP  0x8AC67C6F   
--------------------------------------------------------        


-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] 
Sent: Wednesday, November 28, 2001 2:04 PM
To: 'jbohren@opennetwork.com'
Cc: provision@lists.oasis-open.org
Subject: 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 
>   
>

Identity Scope Assumptions.ppt