There are numerous security features available to Agentry applications. In general, these security features are organized into two categories. First are those built into the platform and that may require configuration during implementation. Second are those that are a part of the application deployed on Agentry and are a part of the application definitions and components.
It is possible within the mobile application to define a maximum number of failed login attempts on the client and to then define the required action to take when that maximum is reached. The default behavior of the application is to disable this behavior and it must therefore be defined within the application project within the Agentry Editor. This includes setting the maximum number of login attempts allowed, and one of four lockout levels, with each level increasing in the severity of the action taken by the client application. See Configuring User Lockout for Failed Login Attempts in the Developer Guide: Agentry Applications.
The Agentry Mobile Platform allows the ability to attach documents to objects and to both download and upload them to and from the client application. When implemented for environments in which iOS devices are used, the default storage location of the attached documents on the client device will result in those documents being accessible via iTunes when the device is connected to that application. A simple change to the storage location of the attached documents, which is made in the application project using the Agentry Editor, prevents these documents from being accessible through iTunes. See Securing Attachments on iOS Client Devices in the Developer Guide: Agentry Applications.
When defining an Agentry Client application, you can set whether to encrypt data stored locally in the Application Definition using the Agentry Editor. An encrypted client encrypts all application definitions and user 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. See Defining Client-Side Data Encryption in the Developer Guide: Agentry Applications.
Since the release of Agentry version 4.4, a secure communications protocol is available called the Agentry Next Generation Encryption Layer, or ANGEL. The ANGEL protocol uses SSL/TLS over TCP/IP communications to encrypt all data synchronized between the Clients and the Server.
The ANGEL protocol is selected as the connect type for a transmit configuration definition within the application. As of Agentry version 4.4, this is the default connect type for all transmit configuration definitions.
During initial synchronization between the Agentry Client and Agentry Server there is a public key provided by the server to the client. This key is a part of the public/private key pair used by the Agentry Server and Agentry Client to secure communications, and to encrypt data on the Agentry Client. In many environments, security requirements dictate the key length of this public/private key pair be increased from the default length of 512. This is accomplished by modifying configuration settings for the Agentry Server and, for existing live implementations, by then also resetting the Agentry Client and by forcing the Agentry Server to generate a new key of a greater length. See Configuring the Agentry Server Public/Private Key Length.
The passwords entered by users during login to the clients are encrypted when sent over the network to the Agentry server using a public key the client receives from the server. This encryption is in addition to any encryption provided by the underlying network protocol (such as SSL encryption in ANGEL). Because of this, Clients are tied to that Server after an initial transmit. It is possible to export a Server’s encryption key and import it to other Servers, should Clients need to connect to more than one, as in clustered environments.
Passwords are not stored on the client, encrypted or otherwise. The client stores a non-reversible mathematical hash of the password (based on the industry-standard PBKDF2-SHA1 algorithm) that it uses to verify the password in off-line scenarios; in addition, the client uses the PBKDF2-SHA1 algorithm on the user's password (using a different random salt value) to generate the encryption key for the client database when client data encryption is turned on. When database encryption is turned on, the client stores the database key, encrypted with the server's public key; the client asks the server to decrypt this key in situations where the user's password has changed (or a new user is logging in) in order to open the database.
When using the ANGEL connect type, both the Agentry Server and the Agentry Clients can be configured to require authentication prior to commencing synchronization. In most cases, the Server authentication is implemented. Client authentication is implemented less often, but is still fully supported.
You must obtain a certificate from a trusted certificate authority (CA) or create your own self-signed certificate, for example by using OpenSSL, and install it to the Server and Client for both Server authentication and client authentication. These certificates are then stored on the Client devices or host system for the Server, with the corresponding trusted certificate entries placed on the counterpart system.