[occi-wg] Renaming the "Link" base type

Fri Oct 8 04:12:44 CDT 2010

  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 at intel.com]
> Küldve: 2010. október 7. 0:57
> Címzett: Ralf Nyren; Csom Gyula; occi-wg at 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 at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Ralf Nyren
> Sent: Wednesday, October 06, 2010 5:08 PM
> To: Csom Gyula; occi-wg at 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 at 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 at ogf.org [occi-wg-bounces at ogf.org] ;
>> meghatalmaz&#243;: Ralf Nyren [ralf at nyren.net]
>> Küldve: 2010. október 6. 16:33
>> Címzett: occi-wg at 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 at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20101008/16e06082/attachment.html 