[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Policy intent examples for eventing
Hi Anish, Thanks for starting the thread. On 11/22/11 9:27 AM, Anish Karmarkar wrote:
I (along with 'et alia') had an action to start a thread on end-to-end policy examples for the eventing space. I'm hoping this email will start the discussion. The examples are not exhaustive. This is just an attempt to get the discussion going.1) confidentialityConfidentiality is on the message and therefore needs to be maintained over all links in the message path. In the case of a broadcast/peer-to-peer model, there is only one hop (at least at a higher level) between a producer and a consumer. But in a broker or hub-and-spoke scenario there are multiple hops. Confidentiality will have to preserved over all hops. One way to do this is to require confidentiality on the SCA channel and require intent matching on all producers and consumers.
Excellent. Just to dig a little deeper, and be explicit about the implementation details....:
Using a broadcast model, there are a number of ways we might accomplish this. Assuming payload is XML, we can use XML Encryption (where does the encryption information end up - does this force us to use SOAP?). Or is there just a shared secret between producers or consumers, and the entire message is encrypted using that shared symmetric key secret (or shared secret + salt value). Or we can use PKI, and encrypt with the private key, then anyone with the public key can get the contents.
If the messaging system allows for metadata fields (likely), then presumably we could stick information about how the message was encrypted (but not the key!) in those headers, and not need XML Encryption.
Question: Given the three or four possible implementation decisions for actually encrypting the payload, do we foresee that assemblers will want to indicate such possible implementations with differing intents? That is, does it make sense to have confidentiality.PKI, confidentiality.XML? (... well, hopefully you get the idea.)
Teasing apart the scenario a little more, though - what if only some of the messages published to the particular channel must be kept confidential? (Just about any global domain channel has this potential problem, but most likely, the default global domain channel clearly has this scenario).
If that's the case, then not all consumers need to have the "confidentiality" intent, any more so than all publishers must have "confidentiality" intent - and it doesn't make sense to apply this to the channel.
Question: Do we allow the use case where not all messages on a channel are "confidential"?
If we go to the hub & spoke model, it is possible that I can ensure confidentiality my merely encrypting the communication to/from each hub. Some customers don't think that's enough, and wish for end-to-end encryption.
Question: Do we need to make an intent distinction between "end-to-end" confidentiality, and "transport"-level confidentiality?
2) authenticationThere are more than one possible usecases here. It may be that the events are sensitive in nature and therefore all producers and consumers have to be authenticated (say payroll related events). In this case, the previous model of intents on the channel and requiring intent matching on all producers/consumers will work. But there is another usecase where producers are required to be authenticated but consumers are not. For example, you want everyone to get earthquake reports, but allow only authenticated producers to generate one. One way would be to use multiple bindings on the channel (via extensions) and get producers to use the binding that requires authentication, whereas consumers use an unauthenticated binding. Another way is to do some kind of channel forwarding/mirroring (behind the scenes) and have two channels, one for producers, one for consumers. Another possibility is to allow one to specify whether intents specified on channels are applicable to producers or consumers or both. I'm sure there are more.
In a pub/sub system, your first case (all producers and consumer have to be authenticated) is just a variation on confidentiality. That is, if you're a consumer, and you don't know how to decrypt a message, then you're not authorized. If you do know how to decrypt a message, then any notion of authorization is useless (well, unless you're the RIAA/MPAA, and you've deluded yourself into believing in the existence of unbreakable DRM).
On the producer side, "authentication" just seems like "signed" to me, or a variation of "integrity"
-Anish -- --------------------------------------------------------------------- To unsubscribe, e-mail: email@example.com For additional commands, e-mail: firstname.lastname@example.org