Hi Gyula,

You hit one of the areas of occi that pushed off to a later version of the specification and a very real issue for the whole of cloud computing. You should join Steve Holcombe's linked in group "data ownership in the cloud". It been a bit dead lately ...

 Occi's general approach towards ownership and credentials was adopted/inherited from http.  The http 1.1 spec supplies a mechanism  to initiate authentication requests, transfer authentication credentials and return authentication request responses. It does not  provide any approach or mechanism to manage credentials.  Authorization is implied to some set of resources residing behind the authenticator gate, where another set of constraints, outside of the http scope,  guide any need of additional authentication and authorization.

Our requirements for credential management introduces use cases not currently addressed by http specification. 

Ownership has been a area of interest for several groups over the past few years. Governance, stewardship, custodial practices, and authority are always buzzing around, but little progress is made. Legal issues and the lack of standard practices are high hurdles to clear.

Credential management has issues as complex the data ownership. Ownership is governed by negotiated policies, however, local, regional and national mandates impact provider management capabilities. For example, if a set of provider created credentials need to be changed by the consumer, a much different set of capabilities are required than if credentials created then email to the consumer.

I've been struggling with proposing an approach for occi. I feel that occi should contain a meta data object that "links" to a credential instantiation and its associated meta data.

In the occi domain there may be several actors creating credentials. In cases consumers may share credentials between users accessing a common resource. In other cases, each resource consumer has unique credentials.

Consumers may have access to an external resources through a proxy. The proxy may require unique credentials from each consumer. The connection between the proxy and the provider may have a different credential hidden from the consumers.  An example of this type of resource is data libraries with a corporate account employees each with their unique credentials proxy though a common gateway with credentials to a data provider.
 
Private clouds can have compute resources with multiple consoles. Each console may have multiple credentials permitting multiple operators access to the console.  In this case the occi administrator is supplying the credentials to the occi configuration.  Private clouds deployed with third party data services could also follow the user case above.

Another private cloud use case involves both authentication credentials and encryption keys to gain access to storage data. The storage resource would require  both credentials and a key or key identifier. The more likely scenario is the private cloud management application would maintain the key and automatically send it to the storage during instantiation. That is if its not on a key card.
 

I have a quick breakdown:

Credential Issuance: (n is multiple credentials)
Immutable-ish credentials issued by a provider to the consumer.   Pn--->C
Credentials issued by the consumer to the  provider.     Cn--->P
Temporary  credentials issued by a provider, then changed by the consumer. Pn--->C, [Cn--->P or multiple C--->P]

The pattern above can be applied to resources:

Credential Issuance: (n is multiple credentials)
Immutable-ish credentials issued by a Resource creator (occi system) to the consumer.   Rn--->C
Credentials issued by the consumer to the  Resource provision defnition.     Cn--->R
Temporary  credentials issued by a Resource creator (occi system) , then changed by the consumer. Rn--->C, [Cn--->R or multiple C--->R]

In practicality, the creating the resource could only issue one credential, the user credentials could be appended later. But, taking a template of the occi system and move it to another provider a serialized process and could be inconvenient, or a time consuming serial activity.

Introducing formalized credentials to Resources sort of  breaks the network resource model. The network resource is actually to (2)  components, a virtual NIC and a gateway. The gateway may need credentials to access it. If the gateway is connected to a VPN (as an external resource), a set of credentials would have to be sent to the VPN endpoint.

During initialization,  we need a way to communicate authentication results fromm the occi system to the consumer.

I'm looking at the oasis kmip specification to help define some key and certificate definition. They support certificates.

Home Page: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip
Docs: http://www.oasis-open.org/committees/documents.php?wg_abbrev=kmip

I'll get the first swag at the section in the extension section tomorrow.  After finishing console..

-gary


On 10/7/2010 4:48 AM, Csom Gyula wrote: 
The challenge is the ownership information. To put it simply: OCCI may lack authz but I think it cannot lack 
ownership information. That is it must handle identity information during resource creation. I didn't have 
time to read through authentication, yet. So my question is: 

Does OCCI receive identity information on resource creation? 

Reason:

(1) Authorization relies on ownership information (besides others), it must link cloud resources and users. 
Without the knowledge of ownership no authz could ever work.

(2) Question: who  will record ownership information? If OCCI does this I have no question. However
if it doesnt then the external system must do this. 

(3) Question: How will an external system record ownership information? I see 2 basic scenarios (though 
others might be possible as well):

(a) An external (proxy like) system recieves the create request first which is then forwarded to OCCI. In this case 
the external system must be OCCI-aware in order to extract ownership information. But can we expect from a 
generic authz system to do this? I would say no. Generic authz systems are generic not OCCI-specific:)

(b) OCCI receives the create requests first, in this case OCCI must be aware of the identity in order to push 
ownership information to the authz system. 

Hence in either case OCCI must deal with identity/ownership: either record it or pass it through.

Note that this is just a quick analyis:)

Cheers,
Gyula
________________________________________
Feladó: Edmonds, AndrewX [andrewx.edmonds@intel.com]
Küldve: 2010. október 7. 0:57
Címzett: Ralf Nyren; Csom Gyula; occi-wg@ogf.org
Tárgy: RE: [occi-wg] Renaming the "Link" base type

Yes - really OCCI will not define authorization or anything AAA/IdM but merely expose a way, by extension, to point/discover to such systems at most.

-----Original Message-----
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren
Sent: Wednesday, October 06, 2010 5:08 PM
To: Csom Gyula; occi-wg@ogf.org
Subject: Re: [occi-wg] Renaming the "Link" base type

Hi,

Authorization will likely not make it to the first version of OCCI.
Authentication will be available though. You are however free to implement
"users" as a sub-type of Resource and then use ResourceLink to associate
users with resources.

regards, Ralf

On Wed, 06 Oct 2010 17:01:11 +0200, Csom Gyula <csom@interface.hu> wrote:


Hi,

Do you plan to add authorization support to the protocol? That is will
OCCI handle users and
ownership information? Just because ownership means a "link" from a
resource pointing to a
user...

Cheers,
Gyula
________________________________________
Feladó: occi-wg-bounces@ogf.org [occi-wg-bounces@ogf.org] ;
meghatalmaz&#243;: Ralf Nyren [ralf@nyren.net]
Küldve: 2010. október 6. 16:33
Címzett: occi-wg@ogf.org
Tárgy: [occi-wg] Renaming the "Link" base type

Hi,

It is easy to confuse the OCCI "Link" base type with HTTP "Link Header"
and the general term of linking.

Therefore it was proposed during today's conf call to rename the base
type
"Link" to "ResourceLink". That way we let the name make clear what the
Link is used for, i.e. linking Resources.

Would appreciate your comments. Deadline is on Friday.

regards, Ralf

_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg