OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cloudauthz message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cloudauthz] a definitino of 'Entitlement' - proposal


David,

The case where a Resource Owner does not know, by default, who and how uses the Resource is typical in the Orchestration Pattern of SOA Services (OASIS SOA RAF provides definition od such services that is technology agnostic).

The only way for the Resource Owner to find where requests come from is to monitor them. However, this monitoring is not required in any specifications. Also, even knowing a network address of the requester, there is no way to verify the requester's identity.

I am describing a case of implicit Service Contract based on the publicly announced policies of the Service Description (both Service Contract and Service Description are defined in the OASIS SOA RAF and have almost nothing to do with WSDL). Example: a shopper in a store uses implicit Service Contract whhile all duties/rules, obligations and guarantees are publicly declated up-front. In this case, the shop owner does not even check identities of the shoppers (payment control over the cardholder identity relates to to the Paymanr System, not to the Shop, and may be omitted when payment is done in cash).

So, an Orchestration Conductor-service (or process) looks up for suitable functional services and invokes them without informing them, based only on their Service Descriptions. This allows functional services to participate is as many cooperations (Orchestrations) as needed. If a functional service does not want such usage, it creates its Service Description in a way that requires explict negotiation/contact with a potential consumer.

BTW, a pattern of Global Choreography in the WS-CDL means always require explict contact and knowledge of each participant and, moreover, modification of participants for each new choreography. This makes aforementioned Choreography pattern unsuitable for independent services such as Cloud services.

I hope, this helps to understand that when dealing with really independent entities (that we have not met inside the corporate boundaries), security means that we used to deal with might not work or work in different ways.  For example, a Cloud Provider as a Resource Owner wants to authorise access to its service using its own Entitlement Solution (system). But the Cloud consumer does not want to use that solution becuase it is too costly or becuase it is not under the consumer's control. Technically, there is no problems but commercially and politically - a lot. Well, this is a different topic altogether.

Regards,
- Michael Poulin

 

----- Original Message -----

From: David Chadwick

Sent: 01/22/13 09:18 PM

To: Mike Poulin

Subject: Re: [cloudauthz] a definitino of 'Entitlement' - proposal


 
I am intrigued to know more about resource owners who have no idea who 
is consuming their resources. Please tell me more 

David 

On 22/01/2013 14:33, Mike Poulin wrote: 
> 
> 4) in my practice, a Resource owner did not always control the policy 
> and the access; in many cases the resource owner was not even aware 
> about who and how consumed the Resource. 

--------------------------------------------------------------------- 
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at: 
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]