Alternative methods for JSON-RPC authentication
#1
I've been working on a kind of web interface for XBMC (see http://forum.xbmc.org/showthread.php?tid=168296). I have a few questions regarding the JSON-RPC API and the way authentication is performed.

1. Is it possible to create a set of credentials that can only access certain parts of the API (and preferably not the standard web interface at all)?

2. Would it be possible to implement alternative authentication methods? Currently the username and password has to be provided in the URL or as HTTP headers. Some form of token-based system would be great, although I'm not sure how exactly it would work and how it would be beneficial. If someone has some good ideas regarding this, please post!
Reply
#2
to 2.
If you don't know in which way this would have any benefits - why are you requesting it then?
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#3
(2013-07-03, 12:36)Memphiz Wrote: to 2.
If you don't know in which way this would have any benefits - why are you requesting it then?

Well, I started writing before I thought the whole thing through, that's why I added "if someone has any good ideas" at the end.

Do you have any advice on #1?
Reply
#4
#1:
Are you talking profiles support for JSON-RP: https://github.com/xbmc/xbmc/pull/2049
Reply
#5
(2013-07-03, 12:54)Robotica Wrote: #1:
Are you talking profiles support for JSON-RP: https://github.com/xbmc/xbmc/pull/2049

Not really. Basically what I'd like is a set of credentials that can only call Files.PrepareDownload and access the /vfs location.
Reply
#6
Something like that is not available afaik...
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#7
I have a very old branch somewhere that introduces authentication to JSON-RPC. Every client has to provide some credentials and a list of permissions it would like to use. That list is presented to the user which can decide whether to grant access to the client or not. It works very well over TCP and WebSockets but requires Cookies over HTTP which is not ideal.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#8
(2013-07-04, 19:21)Montellese Wrote: but requires Cookies over HTTP which is not ideal.

That is indeed not ideal.

In the scenario I described earlier (a user being able to access /vfs only), one possible solution would be to require a token in the URL, where the token would be something like sha1(username + password + vfsPath). That way each URL to the VFS would have a different token, and it wouldn't be possible to guess the token without knowing the username and password.

To illustrate:

http://xbmc:[email protected]:8080/vfs/%2...64-DON.mkv

VS.

http://example.org:8080/vfs/%2fmedia%2fS...hkjfhdkjfh
Reply
#9
First of all my work only covers authentication for JSON-RPC requests, not for webserver access in general.

In your token idea, how does XBMC know about the username and password of the client? First there needs to be a way to tell XBMC about the actual client and its credentials so that XBMC can ask the user whether he wants to grant that specific client access to whatever he requests.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#10
@negge

You're talking about two different things:

1) Authentication - Authentication refers to the process where an entity's identity is authenticated, typically by providing evidence that it holds a specific digital identity such as an identifier and the corresponding credentials.

2) Authorization - The authorization function determines whether a particular entity is authorized to perform a given activity, typically inherited from authentication when logging on to an application or service. Authorization may be determined based on a range of restrictions, for example time-of-day restrictions, or physical location restrictions, or restrictions against multiple access by the same entity or user. Typical authorization in everyday computer life is for example granting read access to a specific file for authenticated user. Examples of types of service include, but are not limited to: ip address filtering, address assignment, route assignment, quality of Service/differential services, bandwidth control/traffic management, compulsory tunneling to a specific endpoint, and encryption.

(copied from wikipedia)

You want a set of credentials with authorization limited to accessing the vfs and nothing else. No need for tokens to do that, XBMC could just deny access to any of the other API methods and return an unauthorized error.

An API key could be used in the request to authenticate yourself (solving the cookie issue). A shared secret known by XBMC and the client would then be used to encrypt/decrypt the request. Add a timestamp in there as well and you've also built yourself protection against replay attacks (request older than x seconds -> possible replay attack, discard it).
Reply
#11
IMO encrypting/decrypting JSON-RPC requests etc is a bit too much. It's not like XBMC is being used to store your credit card information or whatever.
Furthermore passing in an API key to a JSON-RPC request is not as easy as it sounds. The JSON-RPC 2.0 specification does not allow for additional properties in the main request object (i.e. the one containing "jsonrpc": "2.0" etc) so it would have to be passed in to every request as a parameter which is very ugly and would have to be added to the JSON schema for every method.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#12
Well associated problem is that currently json over tcp is not password protected and should be one day.

Specifically since the settings to activate json port 9090 is not really clear to end user on what it opens as it s quite more than just previous event server.
Reply
#13
(2013-07-05, 11:46)Montellese Wrote: IMO encrypting/decrypting JSON-RPC requests etc is a bit too much. It's not like XBMC is being used to store your credit card information or whatever.
Furthermore passing in an API key to a JSON-RPC request is not as easy as it sounds. The JSON-RPC 2.0 specification does not allow for additional properties in the main request object (i.e. the one containing "jsonrpc": "2.0" etc) so it would have to be passed in to every request as a parameter which is very ugly and would have to be added to the JSON schema for every method.

That limitation could be overcome by passing the API key as a URL parameter and let the web server handle the authorization.
Reply
#14
(2013-07-05, 17:05)negge Wrote:
(2013-07-05, 11:46)Montellese Wrote: IMO encrypting/decrypting JSON-RPC requests etc is a bit too much. It's not like XBMC is being used to store your credit card information or whatever.
Furthermore passing in an API key to a JSON-RPC request is not as easy as it sounds. The JSON-RPC 2.0 specification does not allow for additional properties in the main request object (i.e. the one containing "jsonrpc": "2.0" etc) so it would have to be passed in to every request as a parameter which is very ugly and would have to be added to the JSON schema for every method.

That limitation could be overcome by passing the API key as a URL parameter and let the web server handle the authorization.

And how do you do that over TCP? There are no URLs there.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#15
(2013-07-05, 18:17)Montellese Wrote:
(2013-07-05, 17:05)negge Wrote:
(2013-07-05, 11:46)Montellese Wrote: IMO encrypting/decrypting JSON-RPC requests etc is a bit too much. It's not like XBMC is being used to store your credit card information or whatever.
Furthermore passing in an API key to a JSON-RPC request is not as easy as it sounds. The JSON-RPC 2.0 specification does not allow for additional properties in the main request object (i.e. the one containing "jsonrpc": "2.0" etc) so it would have to be passed in to every request as a parameter which is very ugly and would have to be added to the JSON schema for every method.

That limitation could be overcome by passing the API key as a URL parameter and let the web server handle the authorization.

And how do you do that over TCP? There are no URLs there.

That's naturally another story, what I was saying is that the scenario would be possible with the HTTP transport.
Reply

Logout Mark Read Team Forum Stats Members Help
Alternative methods for JSON-RPC authentication0