Tutorial: 02 Security

Introduction

UnityBase is platform for building complex enterprise application. So security is one of most important part of platform. UnityBase security mechanism includes:

• different types of authentication and authorization - modified DIGEST, Kerberos, via public/private key, using LDAP
• encrypted communication - either HTTPS or more secure internal mechanism
• audit - all operation is logged to audit tables (both old and new values are logged)
• simple row level audit - ability to memorize creator, modifier and owner of each entity row
• safe delete - ability to mark entity row as deleted without psychically delete it from database (or other store)
• data history - ability to track history of entity row modification and show row content on specified date
• entity-level security (ELS) - ability to restrict access to entity methods
• row-level security (RLS) - ability to restrict access to entity data based on row attribute values
• access control list (ACL) - ability to restrict access to entity data based on security principal assigned for each entity row
• attribute-level security (ALS) - ability to restrict access to entity attribute values based on different criteria
• record signing - ability to sign entity attributes using electronic signature
• PDF signing - ability to sign PDF documents, including visual signatures
• advanced logging mechanism - almost everything server do can be logged without performance lost

In this article we discuss a authorization & authentication.

What Is The Difference Between Authentication And Authorization?

Authentication

Authentication verifies who you are. For example, you can login into your Unix server using the ssh client, or access your email server using the POP3 and SMTP client.

Authorization

Authorization verifies what you are authorized to do. For example, you are allowed to login into your Unix server via ssh client, but you are not authorized to browser /data2 or any other file system. Authorization occurs after successful authentication. Authorization can be controlled at file system level or using various application level configuration options such as chroot(2).

Usually, the connection attempt must be both authenticated and authorized by the system. You can easily find out why connection attempts are either accepted or denied with the help of these two factors.

UnityBase authentication schemas

UnityBase support several authentication algorithm with different level of security. While configuring your application you can set security.authenticationMethods config parameter to array or possible supported authentication algorithm.

Some schemas have it own authorization some are only for a authentication - the last column it the table above note a authorization method.

UB authorization

If future client requests are authorized using UB method, the task of authentication is to elaborate two parameters between client and server: clientSessionID and sessionPrivateKey. With knowledge of a secretWord - something only client is know, we can calculate a authentication header and add it to every request what require authentication.

After authentication all requests to a serve must include a Authorization: UB signature header, where signature is:

signature = hexa8(clientSessionID) + hexaTime + hexa8(crc32(sessionPrivateKey + secretWord + hexaTime));

Adding a time to a signature prevent from a relplay attack (server check time is growing in each request).

For any request server MAY response with 401 - this mean session is expired and client must repeat the authorization.

Authorization signature calculation (JavaScript):

function hexa8(value){
    var num = parseInt(value, 10),
        res = isNaN(num) ? '00000000' : num.toString(16);
    while(res.length < 8) {
        res = '0' + res;
    }
    return res;
};

 function getSignature() {
 var
    timeStampI = Math.floor((new Date()).getTime() /  1000),
    hexaTime = hexa8(timeStampI);

    return  hexa(clientSessionID) + hexaTime + hexa8(crc32(sessionPrivateKey + secretWord + hexaTime));
 }

UnityBase Administration (UBA) model

The basis of all security mechanism is UnityBase Administration (UBA) model. To enable build-in security developer must include UBA model to application domain.

This model define entities:

• uba_role - security roles list
• uba_user - user list
• uba_userrole - user roles
• uba_usercertificate - user certificates (used for public/private key authentication schema)
• uba_els - entity level security information
• uba_als - attribute-level security information
• uba_audit - audit of security related operations
• uba_subject - unity for uba_user and uba_role entities. Used as security principal for RLS and ACL security

If model UBA is not included into domain, UnityBase work in "authentication not used" mode. In this mode there is no Session context for method execution. This mode can be used in several cases:

• for simple services what not require authentication
• during database initialization
• for test or developing purpose

Also developer can turn on "authentication not used" mode by comment "authMethods" section in application config.

Password policy

For authentication schemas what based on a password, stored in the uba_user entity (Basic, UB & CERT) administrator can define a policies. The policies is stored in the ubs_settings entity, so the UBS model must be in application domain. In other case default values are applied.

Security audit & dashboard

All security - related operations are added to the uba_audit entity. The interface part is available in the adminUI on the path Administrator -> Security -> Security audit.

For user, specified in the UBA.securityDashboard.supervisorUser setting key (by default this is admin user) also available a Security monitor ( Administrator -> Security -> Security monitor ) feature, where all security related events are logged in the real time. For a real-time communication WebSockets must be turned on both server and client side - see WebSockets.

Integrity checking of the application components

UnityBase Defense edition provide a mechanism of self-checking components integrity.

Application server

For the application server the subject of integrity checking are:

• Application configuration file
• Files and subfolders* in models folders (models listen in the configuration file)
• Files and subfolders* in inetPub folder (defined in serverConfig.httpServer.inetPub)

• Files and folders whose names begin with "_" is ignored during checksum calculation

After set up application on the production environment, the first step is to calculate an application integrity. Command:

>ub -calcIntegrity  

will calculate a MD5 checksum of all application components and write it to system32 folder in the file UB_[applicationServerURL], where applicationServerURL is a full URL of current application. This folder accessible for write only for operation system Administrator, so the command should be executed using Administrator rights.

Every time application is starting, UnityBase will calculate a current application checksum and compare it with checksum, calculated by -calcIntegrity command. If the checksums do not match the application will be terminated with exit code = 1.

Client side

In the security environment instead of usual HTML browsed UBDefenseBrowser must be used. For the UBDefenseBrowser the subject of integrity checking are:

• UBDefenseBrowser browser itself and all it components
• offline application part

After set up UBDefenseBrowser on the client, the first step is to calculate an application integrity. Command:

>RunSecureBrowser.cmd -calcIntegrity  

will calculate a CRC32 checksum of all client components.

Every time client part is starting, it will calculate a current checksum and compare it with checksum, calculated by -calcIntegrity command. If the checksum do not match the application will be terminated with exit code = 1.