Autonomous delegated authentication

Notes before installation

Oplon introduces delegated authentication in all communications between sensitive components.

Implementation is gained from mission-critical datacenter experience to increase security and decrease the chances of unauthorized use of procedures within the datacenter.

The use has been specifically designed for complex environments where you can delegate some users or groups of users to be administrators of their specific components.

In addition, programming automation functions through remote shells or netsh, even if protected with encrypted passwords and centrally recorded logins, exposes modern, virtualization-based datacenters into serious danger. Today's ability to load an entire operating system into virtualizers on Personal Computers drastically compromises security by giving you the ability to remotely perform highly dangerous procedures, through cloned virtual machines, if performed to produce damage.

Business-continuity and Disaster-Recovery procedures require you to write lots of scripts that interact at various levels of the datacenter, often with administrator/root privileges. A simple malicious operation to reverse storage replicas, such as a cloned operating system, can cause incalculable damage.

In this regard, all the component password files Oplon encrypted and usable only from the location and operating system on which they originated. Any system cloning or theft of authentication files makes the files unreadable and therefore any operation is not possible.

This document is for configuring user authentications and delegated authentications only. For the installation of components Oplon reference the installation documents of the individual products.

Introduction

Implementing Access Authentication Oplon is based on 4 key points:

1. encryption of authentication repositories

2. source of authentication file creation

3. separation of user and delegated authentication

4. autonomy over the infrastructure to be managed

The first (1) point is very important as the authentication files are encrypted to allow their visibility or readability with the only tools made available by the platform Oplon

The second (2) point poses a significant improvement in safety. All files are unreadable, even from the tools Oplon, whether they are copied or used on cloned virtual or physical machines.

The third point (3) separates the management of human users from delegated users or systems Oplon automation or routing as well as Oplon Application Delivery Controller, Oplon Commander Decision Engine And Oplon Commander Work Flow they can interact across multiple levels of the datacenters.

The fourth point (4) highlights how the authoritarian system must be fully autonomous from the infrastructure it needs to manage. The delegated permission to the action is therefore completely unrelated to, for example, Directory Server, which may not be available when fail-over procedures are performed.

Reference panorama

Delegated authentication reference panoramas are manifold and can typically be used to delegate subsystems to be administered by groups of people who cannot administer the systems above them.

A case among all, in a hierarchical system

The delegated authentication reference landscape is a set of procedures that must be performed within multi-tiered infrastructure tiers such as Storage Area Network, Database, Directory Servers, Application Servers, and across multiple operational, physical, and virtual platforms: different operating systems, different virtualization systems. A typical business-continuity and disaster-recovery environment scenario.

Oplon Commander Work Flow Allows you to perform the necessary operations through different architectural layers by invoking in one step a remote operation called Remote Workflow Command (RWC from this moment). An RWC operation allows you to run an entire Workflow or Workflow from a designated step or just one step.

Only as an example below is an RWC where #LBL_ADDRESS_RWC_TARGET# is the variable that contains the address on which to perform the operation while selfTestNormalEnd property is the step from which to start running the workflow. For more information, see the LBL_Commander_Installation.pdf manual.

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"

As you will notice in the parameters, there is no permission element such as Login or Password. In fact, the permissions are contextual to the person or automaton that starts the workflow and are propagated to the remote nodes that will perform the operation. Remote nodes based on their authorization repository will check whether the request is from a secure source, and in that case they will do so.

User permissions

User permissions are the permissions that are used by people who are going to work with the tools Oplon. For example, when you start Oplon Secure Web-Based GUI and request a user authority password login:

User permissions are set up the first time by using the lblsetup command with the user setting with root permissions and the primary delegate user.

Delegated permissions

Delegated authentications are used to authorize an operation that must traverse multiple layers and where the final execution layer does not necessarily know the user or automaton that performed the first operation.

For example, we can assume an organization needs to have three sites with different execute permissions depending on where you want to perform the operation.

Let's say that authorization policies allow Site A to be able to perform operations on Site B and C, but Site B and C can only do things on themselves.

Delegated authentication and authorization is based on a different authoritative repository from the user repository. To be able to use and modify the delegate repository, simply use the web interface with permission to it as the root user.

Summing up the delegated authentication repository must have a single user within it that has been defined as primary. The primary user will be used by the "client" program, that is, the one who requests to do a remote operation, proposing his credentials. The "server" program, that is, the objective of the command, must have a user with the same credentials (login and password). The "server" program does not have to have the same user declared primary, but must contain it in its list of delegated users.

In this case, the delegated action of node A can be taken towards node B because B contains a user with the same login and password even if B is not primary. Node B cannot perform any delegated action against node A because even if it contains the "delegated" login with credentials equal to node A, B will perform an action against node A by exposing its credentials with the "primaryB" login that is not present in node A and will then reject the operation.

The technique is very simple and therefore very effective. This technique also allows, in situations where a strict security policy is not required, to carry out with few settings of self-subsistant configurations.

If we go back to our initial example and implement it completely below a possible authoritarian scheme.

With this authoritarian scheme, sita A alone is able to perform cross-site operations while site B and C can only perform operations within them. If we later want to enable operations between site C and site B, it will be very easy to add the primaryC user to site B.

Conclusions

Technologies Oplon Autonomous Delegated Authentication security with ease and traceability of operations.