Authenticating the Janus API

[Lorenzo Miniero]

Hi all,

just a quick message to notify you about a new feature we added to Janus, that is a very simple token based authentication mechanism you can make use of to authenticate requests. The idea is very simple: Janus doesn't handle any authorization or authentication process, you just provide it with strings that are to be considered as valid tokens; users provide a token in all requests, and if the token is valid (that is, it's one of the tokens you said were valid) the request is accepted otherwise it's rejected. Nothing fancy, but it should be easy enough to integrate with whatever you're using for authenticating your users.

You can find more details here: https://janus.conf.meetecho.com/docs/auth

Feedback welcome!

Lorenzo

[Nolan Darilek]

Ah, this looks great. Authentication was one of the missing pieces I'd
need to completely offload call-handling to Janus, rather than handling
it in my own server. Even this simple mechanism should work well for me.

Out of curiosity, when are these tokens needed? Does every Janus request
require one, or only certain actions?

Also, is this integrated into janus.js yet?

Finally, a somewhat unrelated question, I can start a new topic if it
spins off into something huge. Is there any way to globally monitor call
events? Say I wanted to know when calls begin/end (I.e. audio/video
sending and session terminated) in a single place so I can monitor
session duration. Is there any sort of global event bus? IIRC the web
socket API only lets me get events for sessions I initiate. The token
page brought me to the admin/monitoring API, which I'd hoped would offer
a global stream of this sort. If I can get a global event firehose then
I can push everything to Janus and simply create/revoke tokens when one
of my users is permitted to call another.

Thanks.

[Lorenzo Miniero]

Il giorno venerdì 11 settembre 2015 19:52:25 UTC+2, Nolan Darilek ha scritto:

Ah, this looks great. Authentication was one of the missing pieces I'd
need to completely offload call-handling to Janus, rather than handling
it in my own server. Even this simple mechanism should work well for me.

Out of curiosity, when are these tokens needed? Does every Janus request
require one, or only certain actions?

Right now all requests must include the token. I guess we might limit the scope to only some requests, but I'd keep it for all: if, let's say, we assume we can ignore it for trickle messages, this means other users who know the session and handle ID might send bogus candidates on behalf of the proper user, for instance.

 

Also, is this integrated into janus.js yet?

Nope, not yet, sorry. Now that I think about it, I never integrated the existing apisecret mechanism either there.

I'll do that first thing on Monday.

 

Finally, a somewhat unrelated question, I can start a new topic if it
spins off into something huge. Is there any way to globally monitor call
events? Say I wanted to know when calls begin/end (I.e. audio/video
sending and session terminated) in a single place so I can monitor
session duration. Is there any sort of global event bus? IIRC the web
socket API only lets me get events for sessions I initiate. The token
page brought me to the admin/monitoring API, which I'd hoped would offer
a global stream of this sort. If I can get a global event firehose then
I can push everything to Janus and simply create/revoke tokens when one
of my users is permitted to call another.

No, there's no such thing as of now. I guess this might be added to the Admin API, but this would require some refactoring, as unlike the Janus API the admin API is purely request/response based, no asynchronous events envisaged. If you think that's important, feel free to open an issue on github as a requested feature, so that we can take note of it (I tend to forget things as I age :-) ). This might be a good addition to the new modular-transports branch, since in that branch the admin API is also available over WebSockets and RabbitMQ, which would make the stream you ask for more efficient.

Lorenzo

[Lorenzo Miniero]

Just added both to janus.js, tested it briefly (it's Sunday after all ;-) ) and it seems to work fine.

Lorenzo

[Nolan Darilek]

Cool, thanks! Certainly didn't expect this to be done on a weekend.
Always impressed at your level of documentation/responsiveness,
especially for an open source project. :)

[Lorenzo Miniero]

Just added the possibility to limit the scope of tokens to specific plugins, e.g., if you want a created token to only be able to attach to echotest and streaming but not the other plugins. Details in the updated docs online.

L.

[Fabian Bernhard]

Hi Lorenzo,

If we want to only restrict certain APIs with the token, how would we do this?

We anticipate the following use case:

1) An authorized user can create a video room with the token

2) Everyone can join this video room without the token (or with a token which is not allowed to create video rooms)

Basically, we want to dynamically create video rooms from a server application and not allow others to create rooms.

Thanks and regards,

Fabian 

[Lorenzo Miniero]

Tokens can only be used to limit access to a few selected plugins (e.g., this user can use the EchoTest and VideoRoom plugins, but not the others), but the specifics of each plugin are out of control to the core and its mechanisms. The cause here is that each plugin has its own, plugin-specific, API to communicate with users, which is opaque to the core. If you need restrictions on the VideoRoom APIs themselves, you need to do that in the plugin itself, or wrap the Janus communication on the server side and filter what users can do there.

L.

[Fabian Bernhard]

On Thursday, 31 March 2016 17:03:03 UTC+2, Lorenzo Miniero wrote:

If you need restrictions on the VideoRoom APIs themselves, you need to do that in the plugin itself, or wrap the Janus communication on the server side and filter what users can do there.

Attached a patch that allows to protect the following functions of the video room plugin with an API key: create, destroy, list, exists.

To configure the API key, create a new section "config" in the janus.plugin.videoroom.cfg file with a parameter called api_key. Example:

[config]
api_key = YOUR-SECRET-API-KEY

 

[Lorenzo Miniero]

Fabian,

thanks for the contribution, this looks cool! Since we're in the process of cleaning up the code of some plugins, VideoRoom included, and we have helpers to check secrets and the like now, I might integrate a refactored version of this in the next few weeks. Unless you'd rather do a contribution of your own as a pull request?

Cheers,

Lorenzo

[Fabian Bernhard]

thanks for the contribution, this looks cool! Since we're in the process of cleaning up the code of some plugins, VideoRoom included, and we have helpers to check secrets and the like now, I might integrate a refactored version of this in the next few weeks. Unless you'd rather do a contribution of your own as a pull request?

If you have time then I would be more than happy if you can add it. That way I can see how your best practice for such a feature is and copy it in future improvements. Thanks!

[Lorenzo Miniero]

Il giorno mercoledì 18 maggio 2016 17:26:04 UTC+2, Fabian Bernhard ha scritto:

thanks for the contribution, this looks cool! Since we're in the process of cleaning up the code of some plugins, VideoRoom included, and we have helpers to check secrets and the like now, I might integrate a refactored version of this in the next few weeks. Unless you'd rather do a contribution of your own as a pull request?

If you have time then I would be more than happy if you can add it. That way I can see how your best practice for such a feature is and copy it in future improvements. Thanks!

Ok, I'll have a go at this probably next week (currently abroad for a conference).

Lorenzo 

[Lorenzo Miniero]

I just added a similar mechanism to Streaming, AudioBridge, VideoRoom and TextRoom plugins:

https://github.com/meetecho/janus-gateway/commit/930a4a4c415c8da42759a6a63d0a8f24131d2c03

For all these plugins, to enable it you have to add a admin_key property to [general]. Unlike your patch, though, this property only protects "create", when enabled, and not "destroy" and "exists" as well. In fact, "destroy" is already protected by "secret" (which you can set to something of your liking you only know anyway). For what concerns "exists", instead, you can already limit the visibility by using the "is_private" setting.

I checked this briefly and it seems to be working fine in all plugins: let us know if it's not working as expected in your scenario.

Lorenzo

[Igor Khomenko]

Lorenzo, 

is it possible to use or to connect some external storage/service for tokens?
As I see it's not possible (quickly checked src code)

For example, it could be a lot of cases where users would like to integrate Janus with their existing sessions storage logic. It could be Redis for example.
So Janus should go to this storage to validate tokens.

This feature is must have for such cases.
Do you have any plans?

[Josh Dickson]

Just implement the logic as a proxy and sit the proxy between the client and Janus.

[Lorenzo Miniero]

We don't validate tokens, the Admin API tells Janus which tokens are valid and for what, and we just check the user passes the right ones. Mapping them to external storages and update the tokens via Admin API is up to you.

L.

[Angel G]

Thanks!
What I'd like to do is to plug in my own authentication scheme.
Rationale: I have php APP, the user is already authenticated via PHP session ID. This can be thought of as kind of a temporary user token.
I need to have code on the backend which audits the API calls against user's rights, e.t. you want to create new room, but you're not in the admins database - reject.
Now the only way I see is to proxy (or completely wrap in) the Janus AJAX calls via a PHP script, which will check whether or not to forward the request to Janus.
Particularly for the Videoroom plugin,  I miss the "kick the user out" functionality. The Ban can be implemented again with API proxying.
I thought to destroy the room, force everybody out and then re-create it and expect everybody to auto-rejoin, but it looks .. raw. 

[sol....@rise.tech]

Hey everyone,

I'm working on a mechanism that makes it easier to authenticate users using time-limited tokens.

The current implementation can only blanket-auth the whole API but the idea is to support arbitrary metadata transport in a C API that is available to janus plugins so that plugins like janus-videoroom can authenticate users on a per-room basis and janus itself can authenticate metadata such as plugin access via a single format.

The mechanism works by submitting plaintext metadata including an expiry timestamp along with an HMAC-SHA1 cryptographic signature of the string that proves authenticity. The signature is generated by the application server using a secret key and passed to the client along with other connection information (janus instance, room id, ...). 

As far as I can see that should solve most problems that were mentioned in this thread rather easily. Comments and feedback very welcome, here or on the PR:
https://github.com/meetecho/janus-gateway/pull/1159

[Lorenzo Miniero]

In case you missed this, the pull request Sol has contributed is basically ready to be merged. I encourage you to have a look if you're interested in an alternative (and smarter) way to authenticate the Janus API, and to voice your feedback, especially if you think this still needs work. Sol did a great work at explaining how this works and enriching the documentation, so it should be easy enough to test. As usual, if I don't get any feedback, I'll just merge, probably tomorrow or Monday at the latest.

Thx!
Lorenzo

[Daniel Davis]

When using the HMAC authentication for a video room, can I still set the "allowed" property with any tokens, or does the HMAC auth take over and require that the tokens are signed?

Thanks,

Dan

[Pierre Leroy]

Hi @everyone,

I know I'm jumping very late on this conversation. The work made for HMAC-signed token is really awesome ! Just a quick question: Have we considered using hashing algorithms a bit more robust than sha1 (like sha3 256 for instance)? 

Thanks,

Pierre