Re: [sca-assembly] Action re. SCA Assembly Issue 233

[Eric Johnson <eric@tibco.com>]

Hi Ashok,

Thanks for writing these up.

Some quick thoughts:

"serverAuthentication" - you put the text "Producer is authenticated by the consumer", but this highlights the very real problem that the notion of "server" doesn't appear. I suggest that if we wish for an intent wherein the producer is authenticated by the consumer, we should call that "consumerAuthenticatesProducer", rather than trying to overload an existing policy intent.

"clientAuthentication" - in addition to being overloaded, I don't quite see how this works. What it implies is that the producer has fore-knowledge of its consumers and has some back-channel way to give a consumer an OK at runtime, or that the consumers share a secret with the producer. So I interpret what Ashok is saying here as "no_outsiders". By that, I mean that if messages are sent to, for example, a JMS Topic, only those consumers that already know the shared secret will be able to read the message. Either that, or that the JMS Topic is deployed such that it narrowly authorized to just the producers & consumers of a particular composite.

"mutualAuthentication" - since I take issue with the names of "serverAuthentication", and "clientAuthentication", I don't think it is obvious that the combination of the two makes sense, and even if it does, I wouldn't call it "mutualAuthentication".

"authorizaton" sounds very much like clientAuthentication - which again suggests that we've got an issue.

Of course, part of the point of exploring the list of which intents might make sense is to understand where they might be applied. I assert, having looked at this list of all the intents that Ashok listed, that the only place it makes sense to apply intents is on a channel (which coincidentally, is the only place we allow bindings).

-Eric.


On 10/26/11 8:50 PM, Danny van der Rijn wrote:

serverAuthentication
clientAuthentication

Can these intents be specified without talking about who does the authentication?  In an earlier thread Jim and Sanjay tripped over the question of the transaction boundary (producer -> consumer, or merely producer -> "channel" or "SCA runtime").  Authentication is the same.  Your text, Sanjay, says:

These intents ensure that the consumer is allowed to receive events from a producer and the producer is allowed to send events to a consumer.  They seem useful for eventing. Not sure where these intents should be applied.

which is actually about authorization.  Authentication is a lesser requirement.  I understand producer identification - the ability to know who produced an event, but I'm not sure I understand consumer identification, or to whom it goes.
It may make sense in a peer-peer mechanism, but far less so if you're using a hub-and-spoke like JMS.  In the JMS case, it's far more common for producer and consumer to identify themselves to the JMS server, and not to each other.  The consumer may or may not get information as to who the producer is (for JMS, it does, but I'm only using JMS as an example), but the producer will almost certainly not get any information as to who consumed its messages.

mutualAuthentication has similar issues.

confidentiality - not sure if the question is in scope, but there's a big difference as to who decides who's authorized, and how that happens.

not sure how "transport" or "message/event" qualification would work.

authorization - you say this doesn't apply to eventing.  If not, how would confidentiality (" The contents of the event are accessible only to those authorized to have access") work?  You seemed to imply authorization in your comments on authentication.

Danny

On 10/26/2011 7:38 AM, ashok malhotra wrote:

See the attached doc as a first cut at which SCA Policy intents apply to eventing.
Needs discussion.

---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org