Introduction
Presentation
----------------------------------------------------------------------------
Overview
First of all, if necessary, ALE can offer you a quote for a Mentoring Service Pack
which will help you with O2G deployment and the use of O2G APIs with the support of dedicated ALE experts.
Contact your ALE representative for more details.
This feature is only accessible by an O2G administrator.
(For some use cases, it is still possible to authenticate as a user to use some available methods,
but which are not recording methods).
This package is not embedded in OXE, and it is able to address the installed OXE(s).
This configuration is exclusively dedicated to the RECORDING feature, all types of OXE subscriber will be considered (including ANALOG).
In the opposite of the main O2G "All Services" configuration, each device to be recorded MUST be first monitored on demand on the right link.
Each device asked to be monitored is dynamically created in the O2G cache and is associated to a user.
Each resource can be accessed through the following kind of URL:
http(s)://<host>:<port>/api/rest/<version>/<resource _name>
Where:
- <host> is the host name or IP address of the server
- <port> is the port of the server
- <version> is the resource version
- <resource_name> is the name of the invoked resources
Third party application can get available API versions by performing a
GET http request on the root URL
(Only GET operation is available on this resource, else 405 HTTP error "Method Not Allowed" in returned)
The structure of the returned body can be found in
RoxeRestApiDescriptor.
http(s)://<host>:<port>/api/rest
Example of response :
{
"serverInfo": {
"productName": "O2G Solution",
"productType": "O2G",
"productVersion": {
"major": "2.7",
"minor": "001.000"
},
"haMode": true
},
"versions" : [{
"id" : "1.0",
"status" : "CURRENT",
"publicUrl" : "https://public-server/api/rest/authenticate?version=1.0",
"internalUrl" : "https://server/api/rest/authenticate?version=1.0"
}]
}
Vocabulary
An application is a third party using the O2G system.
An application can create one or more O2G administrator sessions to interact with all users.
It can also have one or more O2G user sessions.
The person who administers the O2G system.
This person will be able to manage the O2G system, by connecting via an SSH link, using the roxeAdm account with the credentials configured during installation.
It is an O2G user with administrator right.
The installer can create an administrator in O2G system, using the roxe-config.sh tool (or roxe-install.sh during installation).
It is a subscriber of the OXE system.
The installer can manage a subscriber in OXE system, by using MGR tool by example.
It is a subscriber number of the OXE system or an external number.
It is an O2G user with no administrator right.
An O2G user is associated with one OXE subscriber, or more in the case of a multi-device OXE configuration.
An O2G user is automatically created by the O2G system if an OXE subscriber has the A4980 right or if OXE subscriber is managed on demand (depending on the O2G configuration).
- An administrator account :
A O2G administrator account is a O2G session, associated to a O2G administrator.
To create an O2G administrator account, a third-party application must authenticate and log in (open a session).
A login and a password will be used to authenticate to the REST APIs.
(Method: GET https://server/api/rest/authenticate?version=1.0)
This administrator account will be able to use all REST APIs methods.
The login and password used are those administered in O2G by the installer.
A O2G user account is a O2G session, associated to a O2G user.
To create an O2G user account, a third-party application must authenticate and log in (open a session).
A login and a password will be used to authenticate to the REST APIs.
(Method: GET https://server/api/rest/authenticate?version=1.0)
This user account will be able to use only user REST APIs methods.
The login and password used depend on the choice of authentication mechanism, chosen by the installer.
Several authentication mechanisms are possible :
The installer denies user authentication.
In this case, no user can authenticate (no user session).
Only an administrator account must use to perform an action for a user.
The installer authorizes user authentication by O2G.
In this case, the user authentication is checked by O2G (default mode).
It is a basic HTTPS authentication, based on a login/password.
The
login is the QMCDU of the OXE subscriber prefixed by "oxe" (Ex: oxe70120).
The
password is the Secret Code (4 digits), of the OXE subscriber.
The installer authorizes user authentication by OXE.
This configuration impacts all OXEs managed by O2G :
Each OXE must be configured with a local authentication or
with a LDAP authentication (only possible from OXE version N4.507.2).
For a local authentication :
The
login is the Login of the subscriber.
The
password is the Password of the subscriber.
For a LDAP authentication :
The
login is the Login of the subscriber.
The
password is the password of the user defined in the LDAP server.
This attribute is used in many O2G REST API methods.
It corresponds to the QMCDU of the OXE subscriber prefixed by "oxe" (Ex: oxe70120).
This is true regardless of the login used by the authentication mechanism.
History
2.7.4
- modified feature 'Authentication'
- added in representation 'AuthenticationResponse' :
- modified feature 'Session management'
- added in representation 'SessionInfo' :
- added in representation 'SessionRequest' :
- modified feature 'Call control'
- added in representation 'CallData' :
2.7.3
- modified feature 'Call control'
- added in representation 'Identifier' :
- modified feature 'Maintenance'
- added in representation 'DRLink' :
- added in representation 'SystemStatus' :
- modified feature 'Voice Recording'
- added in representation 'DeviceMonitored' :
- added in representation 'DRLink' :
- added in representation 'MonitorRequest' :
2.7.2
- modified feature 'Call control'
- added in representation 'DeviceState' :
- modified feature 'Voice Recording'
- added in representation 'RecordingSrtpKeys' :
2.7.1
- modified feature 'Call control'
- added in representation 'CallData' :
2.7
- modified feature 'Session management'
- added in representation 'SessionInfo' :
- creationDate
- otherSessions
- modified feature 'User information'
- added in representation 'User' :
- modified feature 'Maintenance'
Change logs
Complete changes history can be found here.
Authentication mechanism
All resources are protected by the authentication mechanism.
A dedicated resource is provided to perform user/administrator authentication :
http(s)://<host>:<port>/api/rest/authenticate?version=1.0
The first action for an application is to authenticate on O2G.
Authentication is basic HTTPS authentication, based on a login and password.
The first action for an application is to authenticate on O2G.
Authentication for an administrator
Authentication is basic HTTPS authentication, based on a login/password.
- The login is managed in the configuration file
- The password is managed in the configuration file
The credentials (login and password) are first checked to see if they correspond to an O2G administrator.
JWT authentication is implemented to provide an identifier based on credentials.
This identifier must be passed in a cookie (AlcUserId) in all subsequent HTTPS requests, so that O2G can check their validity.
See below a sequence diagram for a Basic authentication.
Example:
Request
GET http://server/api/rest
Response :
200 OK
Content-Type: application/json
{
"versions" : [ {
"id" : "1.0",
"status" : "CURRENT",
"publicUrl" : "https://public-server/api/rest/authenticate?version=1.0",
"internalUrl" : "https://server/api/rest/authenticate?version=1.0"
} ]
}
Request :
GET https://server/api/rest/authenticate?version=1.0
Authorization: Basic aW50ZXJuYWwyOTphbGNhdGVsMjk=
Response :
200 OK
Set-Cookie: AlcUserId=eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJpbnRlcm5...; Path=/
Content-Type: application/json
{
"credential" : "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJpbnRlcm5...",
"publicUrl" : "https://public-server/api/rest/1.0/sessions",
"internalUrl" : "https://server/api/rest/1.0/sessions",
"expired" : "false",
"login": "oxe1000"
}
Authentication for an user : Secure Access
An installer can authorize or deny user authentication.Enable these options through O2G configuration (root account only).
Several options are possible.
- An installer denies user authentication.
In this case, no user can authenticate (no user session).
Only an administrator account must use to perform an action for a user.
- An installer authorizes user authentication by O2G.
In this case, the user authentication is checked by O2G (default mode).
It is a basic HTTPS authentication, based on a login/password.
- The login is the QMCDU of the OXE subscriber prefixed by "oxe" (Ex: oxe70120).
- The password is the Secret Code (4 digits), of the OXE subscriber.
See previous a sequence diagram for a Basic authentication.
- An installer authorizes user authentication by OXE.
This configuration impacts all OXEs managed by O2G :
Each OXE must be configured with a
local authentication or
with a
LDAP authentication (only possible from OXE version N4.507.2).
For a local authentication :
- The login is the Login of the subscriber.
- The password is the Password of the subscriber.
For a LDAP authentication :
- The login is the Login of the subscriber.
- The password is the password of the user defined in the LDAP server.
The authentication request response provides two additional parameters :
First parameter is the O2G login for further request
Second parameter is a optional boolean which indicate if the OXE password is expired or not.
If this boolean is true, the password provided must be quickly changed using the proper API request
⚠ An expired password can quickly leads to authentication failure
Note : For OXE LDAP authentication, the login is the Login of the subscriber must be the same of the user defined in the LDAP server.
O2G checks the consistency between the LDAP login and the OXE subscriber login.
Session creation
All services are invoked through a session (user or administrator one).
The resource to perform user/administrator session creation is:
http(s)://<host>:<port>/api/rest/1.0/sessions
The session creation request and all the subsequent requests must contain the Cookie AlcUserId with value equals to the one received in the Set-Cookie of the authentication response.
Important: all the sessions are created with an initial time-to-leave of 1800 seconds (30 minutes): To see how to maintain the session, refer to SESSION MANAGEMENT chapter.
Example:
Request
POST /api/rest/1.0/sessions HTTP/1.1
Content-Type: application/json
Host: (server address)
Cookie: AlcUserId=eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJpbnRlcm5...
...
{
[body] : refer to Session Management section
}
Response :
200 OK
Server: Apache/2.4.23
Set-Cookie: JSESSIONID=88C00EA2B3C482E19825F1184D0BB50E.tomcat; Path=/api
Content-Type: application/json
{
"timeToLive": 1800,
"publicBaseUrl": "http://public-server/api/rest/1.0",
"privateBaseUrl": "https://server/api/rest/1.0",
"services": [
{...
O2G Services Through Websocket
O2G REST service may be used through a websocket. This configuration could be interesting in a context where the security must be improved or if
the opening of http ports on the local domain is considerd as an issue.
The solution is to use a reverse HTTP proxy over web socket. The aim is to provide a secure connection setup from the internal network to the external network
in order to tunnel the API requests to internal O2G APIs from the external third party client.
A Web Socket agent run in the internal network (in front end of O2G API) establishes a single connection to a remote Web Socket server in secure mode.
The Web socket agent is included in the O2G solution and may be configured thanks to the O2G configuration tool.
The web socket server side is not handled by O2G solution and it remains to the client to provide it.
A json formatted message protocol is used in the websocket to translate the http REST requests and responses.
In the same manner, the events the client has subcribed to are sent back by O2G through this socket towards the application.
Moreover, an identifier may used as query parameter in the subscription request: in that manner, the events correponding to this susbscription will be automatically
sent to the client through the web socket with this identifier (no need to open a chunk channel).
Here is the Ws protocol map:
Example of request/response for authentication through WS protocol:
Example of request/response for subscription through WS protocol:
Example of event through WS protocol:
Error management
Management of errors returned by REST services invocation follows the common practise which consists of providing as much information as possible to the user.
The returned information structure contains several fields, targetting all possible users of the API: see
RestErrorInfo
The complete list of REST API errors is the following:
| type | code | helpMessage | canRetry |
| NOT_READY | 1000 | The server is not yet available. Please retry later if the initialization is not finished. | true |
| INVALID_SESSION | 1001 | No valid session found for the given identifier. Please logout and login with correct credentials. | true |
| NOT_ALLOWED | 1002 | The operation is not allowed, because of insufficient rights or bad credential. Please contact the installer to fix the problem. | false |
| NOT_FOUND | 1003 | Missing or bad parameter sent by a request on a service. Fix the problem and retry. | true |
| NOT_EXPECTED | 1004 | The request can not be performed due to current user's state.Check the state or fix your request before sending it back. | true |
| NOT_SUPPORTED | 1005 | This operation is not supported. Please check the documentation. | false |
| BAD_PARAMETER | 1006 | Request parameters are not correct. Please fix the problem and send the request back. | true |
| SERVER_PROBLEM | 1007 | Server general problem. Please contact the installer to fix the problem. | false |
Example 1: The service in charge of executing the invoked request is not installed, or the server is not properly configured.
{
"httpStatus":"SERVICE_UNAVAILABLE",
"code":1007,
"helpMessage":"Server general problem. Please contact the installer to fix the problem.",
"type":"SERVER_PROBLEM",
"innerMessage":"AlcChameleonException.PLUGIN_NOT_INSTALLED 'PLUGIN_NAME' plugin is not installed",
"canRetry":false
}
Example 2: Invalid session. The application has to log out, if previously logged in, and retry to log in.
{
"httpStatus":"FORBIDDEN",
"code":1001,
"helpMessage":"No valid session found for the given identifier. Please logout and login with correct credentials.",
"type":"INVALID_SESSION",
"innerMessage":"AlcChameleonException.BAD_FRAMEWORK_SESSION_IDENTIFIER No framework session in API with this ID : ...323437343",
"canRetry":true
}
Representations
boolean'boolean' is a data type, having two values (true and false).
HttpStatusint'int' is a 32-bit number (-2147483648 to 2147483647).
ProductVersionGive information about the version installed on the server.
| Name | Type | Cardinality | Description |
|---|
| major | string | [0..1] | Major version of the product.
This field should help to identify the release of a product. |
| minor | string | [0..1] | Minor revision of the product.
This field is for internal needs. |
RestErrorInfoContains all information from errors sent while invoking REST operations on resources.
| Name | Type | Cardinality | Description |
|---|
| httpStatus | HttpStatus | [0..1] | The HTTP status. |
| code | int | [0..1] | A REST API error code, linked with the above type, to help the user's application to quickly differentiate possible errors. |
| helpMessage | string | [0..1] | A help message, associated with the above type and code, providing a more detailed cause of the error. |
| type | string | [0..1] | A REST API error type, which group all possible underlying errors in a finite number of possibilities. |
| innerMessage | string | [0..1] | This message contains relevant information to help an administrator or support team to find the cause of the problem. |
| canRetry | boolean | [0..1] | An indication for the developer of the application if the error can be solved by modifying the request, or if it is a problem on server side. |
[+] : JSON Example{
"httpStatus": "CONTINUE | SWITCHING_PROTOCOLS | PROCESSING | OK | CREATED | ACCEPTED | ...",
"code": int,
"helpMessage": "string",
"type": "string",
"innerMessage": "string",
"canRetry": boolean
} |
RoxeRestApiDescriptorHigh level information of the server and supported REST API versions.
| Name | Type | Cardinality | Description |
|---|
| serverInfo | ServerInfo | [0..1] | Provide extra information about the server hosting the REST API. |
| versions | Version | [1..*] | List of the versions supported on the server. |
| custoFeatures | string | [0..*] | List of customized feature (informative) added on the server. |
ServerInfoProvide information on the server.
| Name | Type | Cardinality | Description |
|---|
| productName | string | [1] | Friendly description of the product. |
| productType | string | [1] | Short name of the product. |
| productVersion | ProductVersion | [0..1] | Version of the product. |
| haMode | boolean | [0..1] | Indicate if the server is in High Availability mode. |
string'string' represents character strings.
Version| Name | Type | Cardinality | Description |
|---|
| id | string | [1] | Identifier of the version (e.g. '1.0'). |
| status | string | [1] | Status of the given version. 'CURRENT' means this is the latest version on the server. |
| publicUrl | string | [1] | Authentication URL to use from public (i.e. internet) access. |
| internalUrl | string | [1] | Authentication URL to use from private (i.e. intranet) access. |