| Oracle® Communications WebRTC Session Controller Security Guide Release 7.0 E40975-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications WebRTC Session Controller Security Guide Release 7.0 E40975-01 |
|
|
PDF · Mobi · ePub |
This chapter describes the specific security mechanisms provided by Oracle Communications WebRTC Session Controller.
WebRTC Session Controller is built upon the framework of WebLogic Server. In addition to the authentication methods WebLogic Server provides (HTTP basic, form-based, and client certificate), WebRTC Session Controller supports the following:
Identity Asserter: This will validate tokens from OAuth providers (such as Facebook and Google).
HTTP authentication provider: HTTP authentication validates the supplied user name and password against an HTTP endpoint (for example, a REST endpoint).
Authentication of the browser application occurs when the WebRTC Session Controller JavaScript library establishes a WebSocket connection with the server. Depending on the configuration, the server enforces an appropriate HTTP authentication (for example, form-based or OAuth). Once the authentication is successful, WebRTC Session Controller communicates with the SIP network. During this process either authentication is enabled or a user is allowed guest access, depending on configuration settings.
WebRTC Session Controller obtains credentials for authentication by establishing web to SIP identity mapping. WebRTC Session Controller can retrieve IMS credentials (public and private identities or passwords) for a user who has completed web authentication challenges directed at WebRTC Session Controller by the IMS network. Stored credentials may be needed in another node in the WebRTC Session Controller cluster as part of mapping JSON to SIP, for example.
By default, WebRTC Session Controller configuration settings prompt users for a user name and password, using the basic authentication method. JavaScript resources are not protected. The application can be made less or more secure by enabling guest access or necessitating secure access through a TLS (SSL) port respectively.
Web browsers can connect to WebRTC Session Controller over an HTTP port or an HTTP with a TLS (SSL) port. The benefits of using an HTTPS port versus an HTTP port are two-fold. With TLS (SSL) connections:
All communication on the network between the web browser and the server is encrypted. Because it is encrypted, sensitive information will never be in clear text.
As a minimum authentication requirement, the server is required to present a digital certificate to the web browser client to prove its identity.
You can enable TLS (SSL) by using the WebLogic Server Administration Console. See the discussion on configuring TLS in the chapter about configuring diameter client nodes and relay agents in Oracle WebLogic Server SIP Container Administrator's Guide.
Facebook and Google OAuth URLs present wildcard certificates. By default, WebRTC Session Controller does not allow these certificates. Therefore, it is necessary to override the default SSL settings so that wildcard certificates can be handled. For more information, see the discussion on handling wildcard SSL certificates in Oracle Communications WebRTC Session Controller System Administrator's Guide.
To secure client to WebRTC Session Controller interactions, you can use one of the following methods described in this section.
Form-based authentication uses a custom login and error windows that you create. A client requests access to a protected resource. If the client is unauthenticated, the server redirects the client to a login page. The client then submits the login form to the server. If the login succeeds, the server redirects the client to the resource. If the login fails, the client is redirected to an error page.
The benefit of form-based login is that you have complete control over login and error screens so that you can design them to meet the requirements of your application or enterprise policy. However, WebRTC Session Controller does not offer form-based authentication by default. To enable form-based authentication, create a web application using form-based authentication methods. Deploy that web application on the WebLogic server. This allows users who authenticate with the WebLogic server to already be authenticated when they access the client application interface.
Form-based authentication is not particularly secure. In form-based authentication, the content of the user dialog box is sent as plain text, and the target server is not authenticated. This form of authentication can expose your user names and passwords unless all connections are over SSL. If someone can intercept the transmission, the user name and password information can easily be decoded.
Basic authentication is provided by default. Basic authentication uses HTTP headers to transmit the user name and password to WebRTC Session Controller. Basic authentication is not recommended for production systems unless you can ensure that all connections between clients and the WebLogic SIP server instance are secure.
With basic authentication, a client requests access to a protected resource. The web server displays a login screen that requests the user name and password. The client then submits the user name and password to the server. The server validates the credentials and, if successful, returns the requested resource.
HTTP basic authentication is not particularly secure. Basic authentication sends user names and passwords over the Internet as text that is uu-encoded (Unix-to-Unix encoded) but not encrypted. This form of authentication, which uses Base64 encoding, can expose your user names and passwords unless all connections are over SSL. If someone can intercept the transmission, the user name and password information can easily be decoded.
HTTP authentication validates the supplied user name and password against an HTTP endpoint (for example, a REST endpoint). The HTTP authentication provider will also support fetching the user's SIP identity information from the remote end point.
By default, WebRTC Session Controller has an HTTP authentication provider, but it needs to be added to the list of security providers in WebRTC Session Controller. The HTTP authentication provider is invoked whenever a user submits a user name and password to log in to WebRTC Session Controller (using the basic authentication dialog or a form-based login page). This provider sends a request to a configured web service end point with the user name and password in the basic authentication header. If the response from the HTTP end point is 200/OK, the authentication is considered successful. Any other response code indicates that the authentication failed.
For information about configuring HTTP authentication, see Oracle Communications WebRTC Session Controller System Administrator's Guide.
Digest authentication is not supported in WebRTC Session Controller. You can implement your own digest authentication provider by using a separate web application to authenticate users. After the login process is complete, requests can be made to the application that manages WebSocket connections. For more information, see the discussion on configuring digest authentication in Oracle Fusion Middleware Securing Web Services and Managing Policies with Oracle Web Services Manager, Release 12c.
OAuth 2.0 enables a third party application (such as WebRTC Session Controller) to obtain limited access to protected resources (such as the end user's email address, Facebook friends' list stored in resource servers such as Google and Facebook) with the end user's consent. An access token is given after a request for access is made, and is used to access the protected resources hosted by WebRTC Session Controller.
WebRTC Session Controller provides two components to help customers integrate their login mechanism with OAuth providers. These components are the WebRTC Session Controller Servlet Authenticator, and the WebRTC Session Controller OAuth Identity Asserter. Both these modules are installed by default, but they need to be added to the list of security providers in WebRTC Session Controller.
For information about configuring signaling engine parameters such as client ID, client secret, and OAuth server URL, see Oracle Communications WebRTC Session Controller System Administrator's Guide.
Two-way SSL is a more secure method of authentication than either basic or form-based authentication. It uses HTTP over SSL, in which the server and the client authenticate one another using public key certificates. SSL provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. You can think of a public key certificate as the digital equivalent of a passport. It is issued by a trusted organization, which is called a certificate authority (CA), and provides identification for the bearer.
If you specify two-way SSL (client certificate) authentication, the web server will authenticate the client using the client's X.509 certificate, a public key certificate that conforms to a standard that is defined by X.509 Public Key Infrastructure (PKI). Before running an application that uses SSL, you must configure SSL support on the server and set up the public key certificate. For more information about configuring SSL, see Oracle WebLogic Server 12c documentation.
Anonymous guest access can be granted to any application in WebRTC Session Controller. When a user initiates guest access, a WebLogic Server servlet authentication filter inspects the request before the authentication providers are invoked. If the incoming request matches a WebRTC Session Controller application URL pattern (which is configured for insecure access), and if there are no other authorization headers in the request, then the servlet adds an authorization header. The request goes through the provider chain and the authentication grants the user guest access.
For more information about configuring guest access, see Oracle Communications WebRTC Session Controller System Administrator's Guide.
You can strengthen internal security by securing Oracle Coherence and ports.
Oracle Coherence is used internally within WebRTC Session Controller and its nodes. Coherence security includes securing both cluster members and extend clients. You enable security as required, based on your application or cluster implementation and your organization's security concerns and security tolerances. For a brief discussion of each security feature, see Oracle Coherence Security Guide.
Configure firewalls to restrict access internally. Oracle recommends that port 7001 on the managed servers be disabled and 7002 over SSL be used instead. Enabling 7002 can be done during domain installation; however you must remove the non-SSL port by using the WebOracle Communications WebRTC Session ControllerLogic Server Administration Console. For information about configuring port 7002, see Oracle Communications WebRTC Session Controller Configuration API Reference.
Table 3-1 lists the default ports, their names, and security considerations:
Table 3-1 WebRTC Session Controller Default Ports
| Value | Description | Security |
|---|---|---|
|
7001 |
The administration HTTP port |
Allow this port external access for the managed servers, but not for the administration server. It is recommended that you disable this port and use an SSL port instead. |
|
8088 |
The Coherence port |
Restrict access from outside of the WSC network for this port. |
|
5060 |
The SIP port |
Allow access to the IMS network from this port. |
|
5061 |
The SIPS port |
Allow access to the IMS network from this port. |
|
4057 |
WebRTC Session Controller Media Engine HTTP callback port |
Restrict access to this port except between WebRTC Session Controller Media Engine and WebRTC Session Controller Signaling Engine. |
|
7002 |
SSL port for admin/http/t3 |
7002 over SSL is recommended over 7001. Enable 7002 during domain installation. Remove the non-SSL port by using the WebLogic Server Administration Console. |
WebRTC Session Controller offers denial of service (DoS) protection (against message floods, malformed requests, and so on) at signaling and media levels.
Media DoS protection includes the following:
Pools of media ports are provisioned by port ranges on each IP interface (thus giving operators full control over the available port range).
All media ports are closed when inactive.
When a signaling (SIP or web-associated) session requires media ports, they are allocated from the appropriate pool.
The allocated media ports are owned by and dedicated to the signaling session.
Media ports attach to a specific remote peer address and are closed to other IP addresses.
When Secure Real-Time Transport Protocol (SRTP) is used (for example, with WebRTC media), additional authentication steps are used to verify the authentication trailer for each SRTP packet.
When released, media ports are returned to the pool and are monitored to ensure that the media ports are fully quiesced (any inactive media ports that continue to receive media traffic are put into quarantine until fully quiesced.)
Media can be monitored to ensure that the actual received codec matches the signaled codec.
Real-time Transport Portocol (RTP) sequence integrity can be checked and invalid packets can be discarded.
On the signaling side, WebRTC Session Controller DoS protection applies to all types of WebRTC signaling methods. Among other measures, you can set the limits for maximum incoming message size, complete message timeout period, and number of file descriptors to help prevent denial-of-service attacks. The separation of signaling and media contributes to the overall security because a DoS attack on the signaling side does not affect the media side, and vice versa.
For more information about DoS protection, maximum incoming message size, and complete message timeout period, see the discussion on reducing the potential for denial of service attacks in Oracle WebLogic Server 12c documentation.
Other ways of improving security for WebRTC Session Controller include securing SIP and handling challenges from the IMS Core.
WebRTC Session Controller offers secure SIP (SIPS) connections, using TLS to secure signalling. WebRTC Session Controller also uses two-way SSL to verify the digital certificate supplied by the client. You must ensure that a SIPS transport (SSL) has been configured in order to use client-certificate authentication. For more information about configuring SSL, see Oracle Database Advanced Security Administrator's Guide.
When you receive a challenge from the IMS core, you can handle it in the client (on the home page) because challenges are propagated to the client side. WebRTC Session Controller propagates the challenge to the client side only if there is no private identity and private password in the security context. No challenges will be made to WebRTC Session Controller if you set up the IMS network so that WebRTC Session Controller is seen as a trusted entity.
You write your own WebRTC Session Controller authentication module that handles the web user authentication. This authentication module can be a Groovy script that sets up a security context to be used when receiving challenges. The Groovy script fetches the IP Multimedia Public Identity (IMPU) or IP Multimedia Private Identity (IMPI) and the secret key information, which is needed to fill in the SecurityContext object, and adds that information to the public credential set of the security context subject. When a user logs in to the web application page, this Groovy script is invoked and is passed the authenticated subject. The authentication provider populates credential information (web ID, SIP public ID, SIP private ID, SIP private password, and so on) into the authenticated subject. This security context is used towards the IMS network. The Groovy script is used to build the security context information from the authenticated subject. It then fetches the IMPU, IMPI, and secret key information.
Alternatively, you can configure the P-Asserted-Identity header in the groovy script. For example, if the login identity of the web application user is configured as the subscriber's IMPU, then the IMPU can be used in the P-Asserted-Identity header.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
