Forum

Stream ID & Authentication

Mark P. 2020-06-02 19:32:18 UTC in Nimble Streamer

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.

Mark P. 2020-06-02 21:34:51 UTC 

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.

Alex Pokotilo 2020-06-03 04:37:37 UTC 

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

Mark P. 2020-06-03 07:45:07 UTC 

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.

Mark P. 2020-06-03 08:56:39 UTC 
Mark P. 2020-06-03 15:55:17 UTC 

" 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)

Mark P. 2020-06-03 16:39:48 UTC 

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.

Alex Pokotilo 2020-06-04 06:16:25 UTC 

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.

Mark P. 2020-06-04 14:37:35 UTC 

"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.

Yury 2020-06-23 03:22:32 UTC 

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.

Yury 2020-06-23 03:23:26 UTC 

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

We'll update Nimble website accordingly soon.

Post a reply


Post a new question

Categories:

Tags:

nimbleNimble StreamerFAQHLSDVRRTMPhlsnimble streamerABRcachewmsauthNimbleAPIdvrapirtmpSRTtranscoderffmpegVODsrtfailoverDASHsldpstreamingrtspwmspanellivevodudppaywallsubtitlesDispersaRTSPSLDPvideoyoutubeabrlivestreamingmp4WMSAuthMPEG-DASHpay-per-viewgeodashstreamerbandwidthedgeWMSPanelWindowsUDPencryptionhttpswhite labelconfigsmilmulticastsslFFMPEGMPEG-TSaudioCORSchunksraspberry pire-streamingmpeg-dashperformancecorsadvertizervlcrepublishingcloudfrontDRMS3user agentandroidrules.confplaylistadvertisingipv6MPEGTSFastSpringRAMthumbnailFMLEVATcrossdomainipupdatempegtsSMILRecordingaespushakamaiwowzaserversPullcodecmobileerrorSSLbalanceTranscodem3u8chromecastplaylist_dvrWowzaIDreportingconfigurationbugdownloadpublish controlnimblestreamerdomainLarixRepublishingLarix Broadcasterraspianmpeg-tsloopVidillionHttpschunkAWSawsoriginNDICDNrouteswms panelamazonIPnimble webcam html5UIbitrateRegistration Issuedirect link32-bit Windowstwitchcache_controlitworkmelive abr support mpeg-dashwmspanelapiresumertmp abrbeirutWWDCdubaideep statsCentOS v6.4hls to multicast udpnooblogWowza AgentRemote StorageIIS Smooth StreamingcloudmediaAbrHTTPSHot-linking protectionHDSvaddioalertsjwplayer websitebaselinewhmcsAuthentication in HLSPi4nginx rtmp nimblepriceAV BridgelimitOld logsscte-35VaddioscreencastPI3 Ubuntuview timeattaching domainscontainerinterfacesDVRRecordingloadbalancingmod_rewritemetadatadatmessageWMSCONFIG_HOMEprofilerestreamcostID3 tagsgbpsAxiswmsauthsignhighhds streamlocalciscohls restreaming.net hotlinkVLCniblergentoo install server nimblePublic Iptranscoding using NvidiaPaywall Authdecodertransocding republishingVideo PlayerofflinedocumentationNimble streamer upgradeAliasTrancoderconcurrent-connectionslost trafficfileServer-sideicecast urlrulestoppedNimble Streamer versionmainhot linkingchangelebanonlocationmanifestLarix GroveamfMP4 not playedspacepay per viewseekingonSteam stopped workingdvr_archivesmpeg dashobsTCORaspian BusteropensslHLS vodnginxPlayReadyamazon web servicelimuxdvr stream twiceanalyticspaywalapplicationsdphot-linkAXVVGExpression Encoderblocknvenc7brandingHLS PlayerdebiantrialDASH Playermicrosoft streamMP4errorsrocksoftlog traffic statslive video on demandbandwithserverscreen freezecan't registernimblesessionidFFmpegmultiple originsprogressive downloadABR DASHprivate networkLarge DVR filessourceSnapshotsheaderno WMSPanellive videointerleavinglog nimble analysertmp playbackmac osx installvideo stopvideojswotermarkstreamsvimeohelp erroradaptiveAV1 codecattachmentNGINX-RTMPJWPLAYERload balancecache expiryvod no soundconcurrent connectiondvr streamconnectivityUbuntu 20 ARM - AWSunique visitorcdnvsomlive stream4Kcrossdomain more then 1 domainViewer StatsWidevinecpumpeg2tsDelayServer-Side-Task-Controldisk migrationnot foundCPU LoadpullAWS 3buttscreen capturestereo to monoAS3drmresourceaes encryptionsubscriptioninstall players setup ready to gotwitch larix broadcaster androidDVRSettingsDelete recordsAppleTranscoderLive streamingsecurityABR HLS Bitrateslive pull settingsWMSPanel settingsrtmp for YouTubevideo loopstarttime duration seekpointrebootudp streamingoutratemonitoricecastnimble streamer vod hls transmuxingloggingapi accessDeep statsloadbalancerlearnerweb playernimble.confrtmp republishing transcodeIIS Media Servicsinsert logocontent-dispositiondvr streamsautomationnimble streamer web server php script pageNimble Streamer APIlivestreamAVCaptureMovieFileOutputblock downloadNimble CapacityABR DVR problemNimble ServerPost processingadd_chunk failedfake extensionMPEG DASHUbuntu artful 17.10Transcoder MPEG DASHLive SwitcherRTMP republishnot to stealLive Broadcaststatus:errorFFMPEG;RTMP;I/O errortranscodingPIDHotlinking ProtectionStreaming routefacebookMPEG-Dashlarix broadcasterbroadcasterOSXpaymentstatspremium featureserver incorrect timeThumbnailsreloadLiveLIVEadvp9contentRTMP RepublishdemandHow to do live stream with multiple audio trackssaiDVR Setting limitProgressivenimble aliasesrmtpno internetHLS Streamingthumbnail dvr-thumbnailLoad-Balancingnimble streamer mpeg-ts multiple inputswmsAuthSignsoundHLS Meta Tag editing.reportsavoid refreshraspberrySecureJetson Nanotranscoder nimbledvr on wmspanelVideo cant be playedS3 AWSuser_agentautomateAndroidBroadcasttranscodevbv-maxratedockerlivestream bitrateVR-360Failoverpublish streamStream Delaytraffichd25AArch64ABR bitratesPacketizingbuilddelaympeg4.movalias routestoragedomain lockVOD HLS streaming on public IPoutputUsers limitcloudflareanalisysscteno soundInvalid frame headerincoming streamwirecasta recordhttp serverHTML5 playerGopNimbleStreamerav1 codecfastspringmp2 audioNimble streamerdata slicesaliasplayer sldpdistributionqataritworkscdnvideo.jsspeedup my videoiOSissuepricinggoogle cloud storagePaywallvideo and audio not matchdissapointmentpay-per-minutesoftware versionadjustdiskstorage space available3.6.1-1RAM LoadtransocderlivestreaminUDP MulticastMax connectioncompatibility protocolsSO_RCVBUFbuffering videoError when installinghow-tomanage_dvrrulesDVRStreamsaws amazonMPEG2 Videologo in streamIOSrestartFallbackhelpnimble on cloudprerollserver ip21SSL requestVP9sha265video audioCross DomainSRT protocolabr fallbackNimble connectionsmd5credentialsFairplayincomingmulti-viewerDVR SettingPORTanalyseStreamIDdurationBandwidthnimble dvrrtpControl APIfallbackbufferRIST Bondingplayoutscte35ubuntu 18Teradek DecoderlatencygpuRaspberrytasks-controlhotlink protectionultra low latencyRaspberryPi4RTMP to SRTwebhookdvr to livebroadcast videoprogressivedynamic linksTLSV 1.2 CertificateQuickTimevideo streamingartifactsrtsp push androidtuningactionscript 3server ssl errorCSSRist

This website or its third-party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the Privacy Policy. If you want to know more or withdraw your consent to all or some of the cookies, please refer to the Privacy Policy.
By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies.