/usr/share/doc/rfc5766-turn-server/schema.userdb.redis is in rfc5766-turn-server 3.2.3.1-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 | Redis database for user authentication and peer permissions has the following schema:
1) For the long-term credentials there must be keys "turn/user/<username>/key"
and the values must be the the hmackeys. For example, for the user "gorst",
realm "north.gov" and password "hero", there must be key "turn/user/gorst/key"
with value "7da2270ccfa49786e0115366d3a3d14d". Alternatively, the password may be
stored in clear text format. Then the key will be "turn/user/gorst/password" and
the key will be simply "hero".
2) For the short-term credentials, the passwords are stored always on clear text format.
So, there will be key "turn/user/gorst/password" and the value will be "hero".
3) For the shared secrets (REST API), several key/value pairs may be used (same as in
SQL schema). The key will be "turn/secret/<arbitrary secret ID>" and the value will be
"<secret>". For example, if we have secrets "hero1", "hero2" and "hero3", then we will
have keys "turn/secret/A", "turn/secret/B", "turn/secret/777" and their values will be
"hero1", "hero2", "hero3". The turnserver will issue command "keys turn/secret/*" it it
will try to use the returned keys in arbitrary order.
4) The "white" and "black" peer IP ranges are stored as keys of the following form:
"turn/allowed-peer-ip/<arbitrary>"
"turn/denied-peer-ip/<arbitrary>"
The meaning of the keys is the same as the meaning of allowed-peer-ip and denied-peer-ip
turnserver command-line option. The only difference is that the option values are "static"
(they remain the same for the lifetime of the turnserver process) but the database records
can be dynamically changed and they will be almost immediately "seen" by the turnserver
process.
5) Example of a Redis user database setup.
This example sets user database for the following security mechanism variants:
* long-term credentials with open passwords;
* long-term credentials with hashed passwords and realm north.gov;
* short-term credentials mechanism;
* TURN REST API with shared secret "logen";
* Black and white IP peer lists used.
The shell command would be:
redis-cli <<!
SELECT 0
AUTH turn
set turn/user/ninefingers/key "bc807ee29df3c9ffa736523fb2c4e8ee"
set turn/user/gorst/key "7da2270ccfa49786e0115366d3a3d14d"
set turn/user/ninefingers/password "youhavetoberealistic"
set turn/user/gorst/password "hero"
set turn/secret/1368426581 "logen"
set turn/denied-peer-ip/123456 "172.17.13.133-172.17.14.56"
set turn/denied-peer-ip/234567 "123::45"
set turn/allowed-peer-ip/345678 "172.17.13.200"
save
!
6) Redis database configuration parameters
TURN Server connects to the Redis and keeps the same connection during the
TURN server lifetime. That means that we have to take care about that
connection - it must NOT expire.
You have to take care about Redis connection parameters, the timeout and the
keepalive. The following settings must be in your Redis config file
(/etc/redis.conf or /usr/local/etc/redis.conf):
..........
timeout 0
..........
tcp-keepalive 60
..........
|