1.1. How ephemeral credentials work 1.1.1. Request 1.1.2. Response This module contains all authentication related functions that can work with ephemeral credentials. This module can be used together with the auth module for digest authentication. Use this module if you want to use ephemeral credentials instead of ordinary usernames and passwords. 1.1. How ephemeral credentials work Ephemeral credentials are generated by a web-service and enforced on Kamailio. This use of ephemeral credentials ensures that access to Kamailio is controlled even if the credentials cannot be kept secret, as can be the case in WebRTC where the credentials may be specified in Javascript. The only interaction needed between the web-service and Kamailio is to share a secret key. Credentials will typically be requested from the web-service using an HTTP POST and provided in a HTTP response with a content-type of "application/json". To prevent unauthorised use the HTTP requests can be ACLd by various means. This mechanism is based on draft-uberti-rtcweb-turn-rest. 1.1.1. Request The request to the web-service should contain the following parameters: * service - specifies the desired service (msrp, sip, etc) * username - an optional user identifier for the service (as would normally be found in the username parameter of an Authorization: or Proxy-Authorization: header) * key - an optional API key used for authentication Example 1.1. Request example POST /?service=sip&username=foo@bar.com 1.1.2. Respons
| Parámetro | Tipo | Descripción |
|---|---|---|
| secret | string | 3.2. username_format (integer) 3.3. sha_algorithm (integer) |
| username_format | integer | 3.3. sha_algorithm (integer) |
| sha_algorithm | integer | 3.1. secret (string) |
| secret | string | The shared secret to use for generating credentials. This parameter can be set multiple times - this enables the secret used for new credentials to be changed without causing existing credentials to s |
| username_format | integer | The format of the username in the web-service response. |
| sha_algorithm | integer | The SHA algorithm to be used for the Hash. |
4.2. autheph_www(realm[, method]) 4.3. autheph_check(realm) 4.4. autheph_authenticate(username, password) 4.5. autheph_check_from([username]) 4.6. autheph_check_to([username]) 4.7. autheph_check_timestamp(username)
4.3. autheph_check(realm) 4.4. autheph_authenticate(username, password) 4.5. autheph_check_from([username]) 4.6. autheph_check_to([username]) 4.7. autheph_check_timestamp(username)
4.4. autheph_authenticate(username, password) 4.5. autheph_check_from([username]) 4.6. autheph_check_to([username]) 4.7. autheph_check_timestamp(username)
4.5. autheph_check_from([username]) 4.6. autheph_check_to([username]) 4.7. autheph_check_timestamp(username)
4.6. autheph_check_to([username]) 4.7. autheph_check_timestamp(username)
4.7. autheph_check_timestamp(username)
4.1. autheph_proxy(realm)
This function performs proxy authentication.
This function performs WWW digest authentication.
This function combines the functionalities of autheph_www and autheph_proxy, the first being executed if the SIP request is a REGISTER, the second for the rest.
This function performs non-digest ephemeral authentication. This may be used when digest authentication cannot. For example, during WebSocket handshake the username may be part of the requested URI and the password presented in a Cookie: header.
This function checks that the username (or username and domain) in the From: URI matches the credentials.
This function checks that the username (or username and domain) in the To: URI matches the credentials.
This function checks that the timestamp in the username parameter has not expired. The autheph_(check|proxy|www) functions all do this automatically, but in a scenario when individual SIP requests are not authenticated (for example, when they are ove
Copyright © 2013 Crocodile RCS Ltd
Copyright © 2017 ng-voice GmbH
