[occi-wg] Renaming the "Link" base type
Gary Mazz
garymazzaferro at gmail.com
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ó: 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
More information about the occi-wg
mailing list