Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Re: [cifer-api] amazon messaging poc

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Re: [cifer-api] amazon messaging poc

Chronological Thread 
  • From: Chris Hyzer <>
  • To: David Langenberg <>, Jim Fox <>
  • Cc: "" <>, "" <>, Rob Carter <>
  • Subject: RE: [grouper-dev] Re: [cifer-api] amazon messaging poc
  • Date: Thu, 24 Jan 2013 16:31:56 +0000
  • Accept-language: en-US

That’s a good idea.  Though it would be nice if the pubsub model if the sender isn’t concerned with who exactly is receiving the messages…  the receivers might change dynamically…


But your idea something to consider.





From: David Langenberg [mailto:]
Sent: Thursday, January 24, 2013 10:06 AM
To: Jim Fox
Cc: Chris Hyzer; ; ; Rob Carter
Subject: Re: [grouper-dev] Re: [cifer-api] amazon messaging poc




On Wed, Jan 23, 2013 at 2:50 PM, Jim Fox <> wrote:


Couple of comments.

We deal with the out-of-order problem a different way.  Since our
present applications use messaging to update the state of group
resources we can simply toss out any updates that arrive after
a more recent update to the same resource has been processed.
This does require maintaining a floating cache of recent resource
update times.  Looking through course enrollment updates for today,
of about 5000 membership updates only two were received out of order.

On the encryption page:

The shared secret is not so hard to revoke or change.  One easy way
to do this is store the shared secrets on a web site, protected by
client passwords.  As each client starts it accesses that page to
get the currently in use secrets.

Public key methods are convenient for signatures, as the sender can
easily distribute its public key (I tend to use MAC instead, though).
However, they are awkward for encryption.  The sender would have to encrypt a message specifically target at each client, encrypted with that client's public key.  Not an attractive situation.


Under PGP you can also encrypt a message to multiple targets.  What's really happening in that scenario is a unique message key is generated & used to encrypt the message.  Then the message key is encrypted once for each target using the target's public key.  Of course, if your objection was to message-size (as each new copy of the message key does increase the message length by a little bit) then yes you do need to weigh the tradeoffs as the number of targets for a message gets large.




David Langenberg

Identity & Access Management

The University of Chicago

Archive powered by MHonArc 2.6.16.

Top of Page