Home
MATRIXX Security
Application Security
Application security includes configuring web applications and gateways.
Application Security Checklist
The following is a list of best practices for application deployment.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
MATRIXX Installation and Upgrade
MATRIXX Configuration
MATRIXX Security
- About MATRIXX Security
- Introduction to MATRIXX Cloud Native Security
  The information in MATRIXX Security is best-practice information and identifies MATRIXX-specific security considerations and implementations. For container-specific and Kubernetes security information, see the third-party documentation.
- Cloud Native Security
  The information here addresses cloud native security and includes recommendations for securing your cloud native implementation.
- Managing Certificates
  MATRIXX uses certificates signed by a trusted certificate authority, or validated by other means, to establish secure communications with another party with the corresponding private key.
- Enabling Transport Layer Security
  Transport Layer Security (TLS) provides secure internet connections by encrypting data sent between a browser, a website, and the website server to ensure that data is transmitted privately.
- Network Security
  Network zones are stacked with increasing proximity to the open internet or DMZ. Each zone is traversed by ingress and egress points through an application or server, with appropriate authentication and authorization for connecting system traffic.
- Application Security
  Application security includes configuring web applications and gateways.
  - Tracking Client Information
    For auditing and tracking purposes, Event Detail Records (EDRs) can include security information included in SubMan API requests or information can be derived from the client making the request.
  - Password Encoding
    MATRIXX applications support md5 and Spring Framework supported password encodings.
  - Configuring and Customizing My MATRIXX Security
    My MATRIXX leverages the Spring Security Framework. This section describes a sample Spring Security implementation that authenticates with the default My MATRIXX web app or with an LDAP directory.
  - Configuring MATRIXX Backoffice Customer Tool Security
    MATRIXX Backoffice Customer Tool leverages the Spring Security Framework.
  - Configuring Active Directory LDAP Authentication
    MATRIXX supports Active Directory LDAP authentication using the Active Directory-specific ActiveDirectoryLdapAuthenticationProvider in Spring security.
  - Application Security Checklist
    The following is a list of best practices for application deployment.
  - SNMP User-Based Security Model V3
    In the configuration file for the component for which you are gathering statistics, configure the parameters listed in security/c_snmp_security.html#concept_fd3_sbr_3qb__table_l1d_3cr_3qb.
- Database Security
  Depending on your MATRIXX environment, you can use multiple external databases.
- OAuth 2.0 Identity and Access Management
  MATRIXX supports third-party identity and access management application integration.
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

Application Security Checklist

The following is a list of best practices for application deployment.

Consider the following when designing your application security:

Configure all channel-level or application-level authentication and authorization.
All API requests must be sent from authorized systems using key credentials. Multiple systems (such as web servers, CRM, ESB, Campaign Management) can connect to an application.
These systems perform their own user level access control; however, in this zone there should be no unauthenticated APIs.
All communication between client and server services or pods is encrypted using HTTPS.
Note that the HTTPS certificate and end point can terminate on a web server in Zone 3. The encryption processing load is cheaper to balance among multiple web servers than application servers in Zone 4. Also, unencrypted HTTP communication can be subject to more restrictive Layer 7 routing rules (for example, to only let correctly formed URL and payload requests through to Zone 4).
Nodes hosting application pods are placed behind a reverse proxy web server where only approved URL paths are permitted from internet.
Most simple distributed denial-of-service attacks are not sophisticated enough to pass these well-formed URL checks, and it is far safer for malformed requests to be rejected in the outer security zones.
Use an API management gateway to secure APIs.
API management abstracts the security logic out of the APIs and applies them at the API interface. This allows fine-grain enforcement of rules through authentication (OAuth) and decisions through an Attribute based Authorization engine (XACML).
User-level authentication and authorization should exist in any web server or mobile back-end (within Zone 2). The Business API Gateway authorizes the connecting service but does not validate user-level permissions.