Autonomous delegated authentication

Back

The implementation is gained from experience in mission-critical data center to increase security and decrease the possibility of unauthorized use of procedures within the/the datacenter.

The use has been specifically studied for complex environments where it is possible to delegate certain users or groups of users to be administrators of their specific components.

Furthermore, the programming functions of automation¬†through remote¬†shell¬†or¬†netsh, even if protected with encrypted passwords and access counted at central level, expose the¬†modern datacenter, virtualization-based in serious danger. Today’s possibility of loading an entire operating system inside¬†virtualizzatori on¬†Personal Computer drastically compromises the security giving the possibility to perform remotely procedures highly dangerous, through virtual¬†machine cloned,¬†if performed to produce the damage.

Procedures for business-continuity and Disaster-Recovery dictate the need to write a lot of scripts that interact at various levels of the datacenter often with administrator privileges/root. A simple operation deliberate of inversion of the replications of the storage, launched for example from an operating system cloned, can cause incalculable damage.

In this regard all password file of components LBL S.A.A.I. Rel. 9 are encrypted and can only be used from the position and the operating system on which they were originated. Any cloning of the system or the theft of the authentication file makes the files unreadable and therefore any operation not possible.

This document is relevant only to the configuration of user authentication and authentication delegated. For the installation of the components LBL S.A.A.I. refer to documents installation of individual products.

Introduction

The implementation of the authenticating access LBL S.A.A.I. Rel 9 is based on 4 fundamental points:

  1. Encryption of the repository of authentications
  2. Origin of the creation of the authentication file
  3. Separation of user authentication and delegated
  4. Autonomy in relation to the infrastructure to manage

The first (1) point is very important because the files of the authentications are encrypted to allow the visibility and readability with just the tools made available by the platform LBL S.A.A.I.

The second (2) point poses a significant improvement in safety. All files are unreadable, even by the instruments LBL S.A.A.I., if they are copied or if they are used on virtual or physical machines cloned.

The third point (3) separates the management of human users by users delegates or by systems LBL S.A.A.I. automation or routing as LBL Application Delivery Controller, LBL Commander Decision Engine and LBL Commander Work Flow that can interact on multiple levels of the datacenter.

The fourth point (4) shows how the authoritative system should be completely independent from the infrastructure that must manage. The delegated permission to the action is therefore completely detached for example from Directory Server that may not be available at the time of the implementation of the procedures for fail-over.

Panorama of reference

The views of reference delegated authentication are numerous and typically can be used to delegate of the subsystems to be administered by groups of people who however may not administer in their turn systems placed above them.

A case between all in a hierarchical system

The panorama of reference of the delegated authentication is a set of procedures that must be performed within the datacenter on multiple levels of infrastructure such as Storage Area Network, Database, Directory server, application server and on multiple operating platforms, physical and virtual: different operating systems, systems of different virtualization. A typical scenario of environments of business-continuity and disaster-recovery.

LBL Commander Work Flow allows to carry out the necessary operations through different  architectural layers by invoking one step a remote operation called Remote Workflow Command (RWC from this moment). An operation RWC allows to perform an entire workflow or a Workflow starting from a step designated or only one step.

Only by way of example below a RWC where #LBL_ADDRESS_RWC_TARGET# is the variable that contains the address on which to perform the operation while selfTestNormalEnd is the step from which to start the execution of the workflow. For further information see the manual LBL_Commander_Installation.pdf.

As can be seen in the parameters is absent any element of authorization as a Login or Password. In fact, the permissions are contextual to the person or robot that initiates the workflow and are propagated to the remote nodes that must perform the operation. Remote nodes based on their repository of authorization occur if the request comes from a trusted source and in this case going to perform the operation.

Step enable= "true"

name=rwcTest""

description="Self Test ab end

waitBeforeExecute "="1000

sysCommandTimeOut "="600000

evaluateReturnCode "= "true"

command="@RWC hostName=#LBL_ADDRESS_RWC_TARGET# workFlow=selfTestNormalEnd

maxRetry "="3"

gotoWhenFalse="abEnd"

returncode value="0"

   Description="OK"

   Result= "true"

User Permissions

User permissions are the permissions that are used by people who are about to work with the instruments LBL S.A.A.I.. For example when you start LBL Secure Web-Based GUI and prompted for a login password autoritativa user:

Setting permissions user is carried out the first time using command lblsetup with the setting of the user with root permissions and the primary user of delegation.

Delegated Permissions

The authentications delegated are used to authorize an operation that must pass through several layers and where the layer of the final execution does not necessarily know the user or the robot that has carried out the first operation.

For example, we can envisage an organization that needs to have three site with different permissions to execute depending on the location from which you want to perform the operation.

Suppose that the policy of authorization allow the site to be able to carry out operations in site B and C but the site B and C can carry out operations only on themselves.

Authentication and delegated permission is based on an  authoritative repository is different from the repository of users. In order to be able to use and modify the repository delegate is sufficient to use the web interface having the authorization as user root.

Summarizing the¬†repository¬†of delegated authentication must have in its inside a single user that has been defined as primary. The primary user will be used by the program “client”, i.e. the one that requires a remote operation, proposing his credentials. The program “server”, i.e. the objective of command, must have a user with the same credentials (login and password). The program “server” must not necessarily have the same user declared primary, but must contain it in your list of users delegates.

Login Password Primary Login Password Primary

———— ———– ———- ———— ———– ———-

Delegated  pwd1 true PrimaryB pwdB  true

Usr1 pwd2 false Delegated pwd1 false

Usr2 pwd3 false Usr2 pwd3 false

In this case the Action delegate of the node A can be carried out toward the node B as B contains a user with the same login and password even if B is not primary. The node B cannot perform any action delegated to the node A in that while containing the login “delegated” with credentials equal to the node A, B will perform an action toward the node A by exposing its credentials with the login “primaryB” that is not present in the node A and that therefore refuse the operation.

The technique is very simple and for this very effective. This technique also allows, in situations where it is not necessary a stringent security policies to carry out with a few settings self-consistent configurations.

If we go back to our initial example and the implement fully below a possible scheme authoritative.

Login Password Primary Login Password Primary

———— ———– ———- ¬† ———— ———– ———-

PrimaryB  pwdB  true      PwdC primaryC  true

Delegated  pwd1 false     Delegated pwd1 false

Usr2 pwd3 false          Usr2 pwd3 false

Login Password Primary

———— ———– ———-

Delegated  pwd1 true

Usr1 pwd2 false

Usr2 pwd3 false

With this schema authoritative only the sita to is able to make transactions cross site while the site B and C can only make operations inside them. If in a second moment we wanted to enable the operations between the site C and site B the operation will be very simple by adding to the site B the user primaryC.

Login Password Primary Login Password Primary

———— ———– ———- ¬† ———— ———– ———-

PrimaryB  pwdB  true      PwdC PrimaryC  true

Delegated  pwd1 false       Delegated pwd1 false

Usr2 pwd3 false   Usr2 pwd3 false

PwdC primaryC  false

Login Password Primary

———— ———– ———-

Delegated  pwd1 true

Usr1 pwd2 false

Usr2 pwd3 false

Conclusions

The Technologies LBL Autonomous Delegated authentication allow a security has never been achieved before with simplicity and traceability of operations.