Stream ID & Authentication

Hello,

If you have a solution that I can use via some API to determine if the stream should be accepted or not, can you please point me to the docs for it?

The addition of new approved stream IDs / keys (from registered users) to a database or file will be automated and I need a way to have Nimble Streamer check if the given ID/key is valid.

If the user is using my app to publish the SRT stream then I'd like to tell them that their ID/key is missing or invalid.

Please point me to the docs for authenticating streams or advise as to how I can only accept streams from registered users without having to configure via WMSPanel for each new user.

Is there some XML or JSON configuration file from which Nimble Streamer can update its list of accepted IDs/keys without restarting?

Please clarify your authentication model.

Thank you.

Correction:

I realize StreamID means something else. What I'm talking about is the StreamKey used for authentication. For example, Twitch uses a StreamKey that is tied to the user's Twitch account. That's what I'm asking in regards to.

Hi,
we are working right now on stream_id with userid -> password mapping.
It will be available in the next week. Please check Nimble release notes/subscribe blog/telegram/youtube to be informed once this feature available

Hi,

The way I imagine it is the stream publishing client gets a token after it successfully signs-in. The token has an expiration date/time and is digitally signed with the server's pubic key (or some such scheme) The token can then be sent by the publisher to the server as stream_id or auth or whatever field the SRT protocol allows for this. The server can then validate the token is authentic and still valid (has not expired) and based on that it agrees to ingest the stream. Otherwise, it returns an authentication error (assuming SRT protocol allows for that) The token would be renewed by the server before it expires (client can be required to re-authenticate with the same username and password (that it has in memory after the user enters them the first time) and reinsert the new token into the SRT stream.

I look forward to finding out whether or not you'll support signed tokens with expiry. It reduces the risk of the token being stolen and re-used by someone which could incur a lot of cost to the user. But I would be happy with any practical and secure way to authenticate that won't be coupled tightly to WMSPanel.

More context here:

https://github.com/Haivision/srt/issues/1313

" in SRT-to-SRT connection, each user can have an individual passphrase known to the server. So that the server can tell this passphrase to SRT (via listener callback). SRT will check authentification, and accept or reject the user's connection attempt."

This is what I need and the passphrase in my case is a signed token generated after the user authenticates via web/https by entering their username and password. The signed token has an expiration time and can be sent to publisher and stored on the server in a database so that when publisher sends the token in the SRT stream it can be validated and user is identified (from the token->user_id mapping or verifying the token is valid was assigned to the associated user_id)

The idea of the SRT callback for verifying user is authenticated via token/passphrase is perfect.

What I don't understand is how the SLDP side will work. Does SLDP support authentication? or is it a free-for-all stream?

None of this has to be tied to WMSPanel but as an option it could be configured from there (and should be possible too from some config file so it can be automated and decoupled from WMSPanel)

After reading the doc here: https://github.com/Haivision/srt/blob/master/docs/AccessControl.md

I have more clarity on the scheme

Here are my updated thoughts based on the doc above:

This is what I need and the passphrase in my thinking would be a signed token generated after the user authenticates via web/https path by entering their username and password into a web app that returns the signed token (that will be the passphrase that I would set on the socket once stream_id gives me the username.) The signed token/passphrase has an expiration time in my case and can be re-generated by before expiration (on server side upon client request) and sent to the publisher, set on the socket once again, sent by publisher with the SRT data, and checked by this SRT library to allow/deny the connection.

The idea of the SRT callback for verifying user is authenticated via token/passphrase is perfect. My only thought about it is that it probably should have an expiration time and it should be digitally signed. If it does have an expiration time then we need to be able to renew it while the stream is live and in progress. If it's not renewed and it expires the stream should be interrupted but it can have any expiration period like 2 hours or more. Alternatively, the expiration of the passphrase/token should not terminate any live stream in progress but should disallow it from being used for a new connection.

I don't have much knowledge of PSK encryption, or how you'd prove that the expiration date in the passphrase hasn't been modified. If the password doesn't expire then it's akin to a hashed password, and that's totally fine if MITM attack scenario (to steal the token) is not possible or not in scope for this feature.

Mark,
please find our plans about SRT passphrase+our view to authorization in my reply to your post here https://wmspanel.com/forum/question/WMSPanel-API-plans starting with " Speaking of access control for SRT"
Please also find what I personally think about SRT traffic encryption future here https://github.com/Haivision/srt/issues/1297
Please also note that we should ask you to wait for this feature and it's description in near future once my view to this subject become a product.
I respect all feedback from our clients but we have 4 parallel threads about this feature so you need wait to get what I want to bring to the product in SRT/streamid field.
I have my own view on this subject and it would be cool if you find something useful to your cases. But I'm not feedback driven in this case so don't wast you time and just wait for new release please.

"I think passphrase now used for both publish authorization and traffic encryption but if we implement DTLS we get traffic encryption out of the box and each vendor can implement authorization based on streamid. This is more secure too as passphrase is used multiple times while DTLS session key is changed on each session and probably during long sessions as well."

This would be exactly what I would do anyway and it's the most credible solution.

If stream_id is a signed token like how JWT is used commonly then the SRT data would have to also include user_id so you can look up in the database by user_id and see if the token is valid.

Such a scheme would not only meet my requirements but is exactly how most modern token based authentication works.

Thank you for starting that issue in the SRT repo.

We've released SRT Publisher Assistance Security Set premium feature set. It includes the support for streamid parameter for Listen mode or receiver among other features.

Please read this article giving overview of this huge feature set:
https://blog.wmspanel.com/2020/06/srt-publisher-assistance-security-set.html
We're also working on related technical articles describing the setup, they are coming soon.

We also support streamid for outgoing connections, that is part of freeware functionality of Nimble Streamer.

We'll update Nimble website accordingly soon.