Authorization for kernel messages

[minrk]

Problem

Authorization introduced in #165 provides a single kernels:execute resource+action combination applied to establishing websocket connections, and from then on, all messages are allowed. However, it will probably be desirable to apply permissions at the message level.

The Authorization system allows for this in general. We only need to provide:

• an authorization check for each message prior to relay
• an action/resource definition for each message type (or should contents be available to consider?)

Proposed Solution

• new action kernels:connect allows the connection itself
• existing kernels:execute allows connection and all messages

I see two choices for defining the actions:

1. mapping of message type to higher-level actions
2. use message type as the action

The advantage of 1. is that it lets configurers more directly indicate what they need, and we can bundle related messages together (e.g. comm can represent comm_open, comm_close, comm_msg, execute can wrap complete, inspect, execute). The disadvantage is that we need to decide beforehand what are the appropriate bundles, and keep those up-to-date with all new message type definitions. If our picks don't suit a given operator's, they are out of luck.

The advantage of 2. is that all possible permission combinations will always be possible, and it's perfectly future-proof for additional message types. The disadvantage is that it's up to the authorization implementation to handle every available message type.

The second question is whether it makes sense to limit messages coming back from the kernel to the client. I think it doesn't make sense to limit _reply messages on the shell channel, but it could make sense to limit IOPub messages (such as execute_input which echoes code other clients may have submitted).

A minor question is whether kernel messages are a separate "kernel-messages" resource, or if this should all be on the same 'kernels' resource.