tree c7b50e241441c60cf7c24eba6490e98261570b24
parent 1dcb4918d6af2d059e0fb9266239146b8479c1d4
author Asim Shankar <ashankar@google.com> 1455249638 -0800
committer Asim Shankar <ashankar@google.com> 1455249638 -0800

jni: security: Add API for notification of changes to the default blessings.

BlessingStore.Default is a somewhat weird function - it says "default"
but practically it is meant for use by servers to reveal blessings to
clients when they don't have any other information about the client.

There seems to be a desire to allow servers to change the blessings they
identify themselves with dynamically (for example, syncbase servers
might want to identify themselves as delegates of all the applications
whose data they are hosting - which changes as new apps connect to it).

Two possible ways of achieving this:
(1) Servers continue to use BlessingStore.Default with an added API
to allow them to be notified of changes to this.
This is what is implemented in this commit
OR
(2) Drop BlessingStore.Default as an API completely and have an
explicit v.io/v23/rpc.Server.SetBlessings method that sets the
blessings used by the server.

I'm a bit torn as to which of these two alternatives is more
appropriate, but it seems that there is a leaning towards this one
since it keeps the BlessingStore as the one place to persist blessings.

One subtlety related to this approach - I haven't figured out
how to return a useful channel in the un-cached agent case
(see changes to v.io/x/ref/services/agent/agentlib/client.go).
But that may not be a practical concern?

Another TODO: Figure out the notification API in Java

MultiPart: 2/5

Change-Id: I43e5352de230d6c63867ecf2c1188aa42ef47880