Administrator

Agentry Security

There are numerous security features available to Agentry applications. The Agentry component supports client data and password encryption, encrypted client-server communications, and authentication certificates.

In general, Agentry security features are organized into two categories:
  • Those that are built into the platform, which may require configuration during implementation, and
  • Those that are part of the application deployed on Agentry, which are therefore a part of the application definitions and components.
To implement security features in Agentry, understand data and password encryption methods, security protocols, client-server communications, and client-server certificate authentication within Agentry.

Client-Side Data Encryption

When defining an Agentry Client application, you can specify whether to encrypt data stored locally in the Application Definition using the Agentry Editor. An encrypted client encrypts all production data and application data stored on the client device. This functionality provides a layer of security for all data stored on the client device by the Agentry Client. See the specifications for details on the encryption strength and protocols used.

WebSockets

WebSockets is a standard for allowing bidirectional real-time communication between clients and servers that is encapsulated within another transport protocol, such as HTTPS. Agentry on the SAP Mobile Platform uses WebSockets to route its binary communication protocol (known as ANGEL in previous Agentry releases) through HTTPS.

WebSockets enable Agentry components to work consistently across the enterprise, in tandem with other SAP Mobile Platform components, and allow Agentry to leverage WebSockets-aware HTTP reverse proxies.

The Agentry Editor automatically converts the transmit configurations of older Agentry applications into WebSockets transmit configurations.

RSA Key Pairs

In addition to SSL certificates, there is an RSA key pair that Agentry uses within its communications. This key pair is generated by the server at installation time, and serves two purposes:
  • To encrypt user passwords that are sent from the client to the server (which is a bit redundant given that we're using SSL; it was originally there for use with non-encrypted transports that Agentry no longer supports).
  • Clients use the server's public key to encrypt the key that is used for database encryption, so that the database encryption key can be decrypted by the server during a user change on the client side.
The strength of this key pair is controlled by a server setting in Management Cockpit. It is the "publicKeyLength" setting in the "Server" section, and defaults to 4096 bits in SAP Mobile Platform.

Client Password Encryption

The passwords entered by users during login to the Agentry Clients are encrypted based on an encryption key received from the Agentry component. This key is the public key portion of a public-private key pairing generated by the server, therefore clients are tied to that server after an initial transmit. If clients need to connect to more than one server, as in clustered environments, you can export a server’s encryption key and import it to additional servers.

This encryption protects user passwords that are entered on clients. The password value is stored and transmitted in encrypted form. It is decrypted by the server when a client connects, and when it is read in by the client during user login. In both cases, the decrypted value is used only for validation of the user; it is not permanently stored.

Trusted Certificates in Agentry

Agentry uses HTTPS for server authentication, which requires a server certificate. That certificate is managed by the Web server that services all of SAP Mobile Platform. Agentry Clients do not support client certificate authentication. With integration into SAP Mobile Platform, Agentry now uses platform-wide security components to define how Agentry Clients trust the server's certificate. Key differences from legacy Agentry configurations include:

  • The Agentry component no longer uses the AgentryServer.pfx file that held the server-side SSL certificate in previous Agentry releases. Agentry now uses the same server-side SSL certificate that is used by the rest of SAP Mobile Platform, because it uses the same Web server.
  • Agentry Clients on Windows no longer use AgentryTrustedCertificates.sst to hold the CA certificate that validates the Agentry component's SSL certificate. Instead, Agentry Clients on all platforms validate the server's SSL certificate by using the trusted certificates that are held by the native operating system. If an in-house CA certificate is needed to validate the server's SSL certificate, then this CA certificate needs to be added to the operating system's trusted CA list using the standard means for the operating system.
  • Agentry no longer comes with a default self-signed SSL certificate accepted by clients regardless of the server's name. Clients now only accept SSL certificates that properly contain the DNS name of the Agentry component. As such, it is not possible to connect an Agentry Client to an Agentry component "out-of-the-box" without either obtaining a valid server certificate that has been signed by a global CA, or by adding the SAP Mobile Platform's generated self-signed certificate to the trusted certificate store on the client device.

Agentry Applications Support SSL Standard

Agentry applications now fully support the Secure Sockets Layer (SSL) standard, including:
  • Alternate names in SSL certificates - Subject Alternative Names are a standard way of adding additional server names to an SSL certificate. The server can handle resolution for alternate names.

  • Wildcards in common names in SSL Certificates - the server can handle wildcards in SSL certificate names, for example, a certificate containing a hostname of "*.sap.com" would match a server name of "myserver.sap.com".

  • Download of certificate chain - an application on the client device can download the certificate chain (root and intermediate certificates), without the administrator having to install the intermediate certificate for each individual application deployed to a device.