Security considerations and other Metadata

[benlesh]

Had a thought around this and I wanted to get an issue for tracking considerations around stream security.

Given that this is a protocol, there needs to be allowances for security, such as token-based authentication, over the stream. WebSockets, which would likely be the choice for dealing with IO streams from browser-land, don't really have any great built-in mechanisms for security propagation. There is an HTTP-based handshake, but not much more.

What allowances, if any, are there for transporting metadata of any sort (including custom security), in a standardized way, with each reactive stream message? For example HTTP makes use of headers for this.

Perhaps this is a non-issue and is covered in another discussion.

[viktorklang]

What kind of security do you have in mind? Privacy/Encryption? Authentication? Authorization?

Here's what I'm thinking:
For Privacy either the transport can be tunneled or the messages of the protocol could use something like DTLS.
For Authentication & Authorization, that would need to be done when subscribing.

Anything related to ever data element needs to be understood by both the publisher and subscriber and as such it can be modeled in the domain?

Did I understand it correctly?

[benlesh]

Yeah, @viktorklang, that will probably do. I just wanted to get the story down there.

So the specifics would be around a common case for Browser Apps which would be token-based auth.

Over a websocket, this could likely be handled at the handshake. However, there are other considerations, like the desire to disconnect or reject requests for more data after a token has been rejected or as expired. Essentially, as a security measure, you might need to be able to kill a long-lived stream connection due to revoked access. In a polling/REST environment, this is trivial, because each request sends the token along with it, and it can be analyzed by an HTTPHandler or Filter. In a streaming environment this gets a little murkier, because there are many, many ways to implement this.

I think it would be great if the RSIO protocol offered some flexibility or guidance around this issue. All too often security layers are tacked on as an after thought. I think as a matter of design, we should at least consider them up front. They might not be a common use case for distributed systems sitting in their own isolated envionment, but they're almost certainly a common use case for connections extending in the browser-land and the general public.

[benlesh]

TL;DR: Signed requests for more data might be desirable for some systems.

[viktorklang]

Yeah, @viktorklang, that will probably do. I just wanted to get the story down there.

Roger

So the specifics would be around a common case for Browser Apps which would be token-based auth.

Over a websocket, this could likely be handled at the handshake. However, there are other >considerations, like the desire to disconnect or reject requests for more data after a token has been >rejected or as expired.

The Publisher is free to signal onError when the token expires. Wouldn't that work?

Essentially, as a security measure, you might need to be able to kill a long-lived stream connection due >to revoked access.

In a polling/REST environment, this is trivial, because each request sends the token along with it, and it >can be analyzed by an HTTPHandler or Filter. In a streaming environment this gets a little murkier, >because there are many, many ways to implement this.

By the sound of it this concern should be done in a different layer in the protocol stack, and I'd suggest that any such token is only sent on change.

I think it would be great if the RSIO protocol offered some flexibility or guidance around this issue. All >too often security layers are tacked on as an after thought. I think as a matter of design, we should at >least consider them up front. They might not be a common use case for distributed systems sitting in >their own isolated envionment, but they're almost certainly a common use case for connections >extending in the browser-land and the general public.

I completely agree. In any case these concerns need to be documented and paired with some rationale for the solution which is chosen.

[benlesh]

The Publisher is free to signal onError when the token expires. Wouldn't that work?

Yeah, I guess I'm mostly concerned with the transport of the security metadata.

By the sound of it this concern should be done in a different layer in the protocol stack, and I'd suggest that any such token is only sent on change.

My concern is that we'll punt and say "TCP or WebSockets can take care of this" when they really don't, at least not when it comes to passing security tokens via some common method. Especially with WebSockets, developers always end up inventing their own security wrappers or tacking in some "headers"-type-thing. This is generally for lack of proper handshake handling. But having written some code around WebSocket handshakes in years past, that stuff is ugly... or at least it used to be.

As long as we clearly define the security story for each supported transport method, I think we're fine. If we don't though, I think early adopters are in for some pain.

[viktorklang]

@Blesh Noted. As someone with an aversion for TCP I hear you loud and clear :)