Vizualizați conținut de ajutor pentru versiunea:

Introduction

By default, AEM uses the Token Authentication Handler to authenticate each request. However, in order to serve authentication requests the Token Authentication Handler requires access to the repository for every request. This happens because cookies are used to maintain the authentication state. Logically, the state needs to be persisted in the repository in order to validate subsequent requests. In effect, this means that the authentication mechanism is stateful.

This is of particular importance for horizontal scalability. In a multi instances setup like the publish farm depicted below, load balancing cannot be achieved in an optimal manner. With stateful authentication, the persisted authentication state will only be available on the instance where the user is first authenticated.

chlimage_1

Take the following scenario as an example:

A user may be authenticated on publish instance one, but if a subsequent request goes to publish instance two, that instance does not have that persisted authentication state, because that state was persisted in the repository of publish one and publish two has its own repository.

The solution for this is to configure sticky connections at the load balancer level. With sticky connections a user would always be directed to the same publish instance. As a consequence, truly optimal load balancing is not possible.

In case a publish instance becomes unavailable, all the users authenticated on that instance will lose their session. This is because repository access is needed to validate the authentication cookie.

Stateless Authentication with the Encapsulated Token

The solution for horizontal scalability is stateless authentication with the use of the new Encapsulated Token support in AEM.

The Encapsulated Token is a piece of cryptography that allows to securely create and validate authentication information offline, without accessing the repository. This way, an authentication request can happen on all the publish instances and with no need for sticky connections. It also has the advantage of improving authentication performance since the repository does not need to be accessed for every authentication request.

You can see how this works in a geographically distributed deployment with MongoMK authors and TarMK publish instances below:

chlimage_1

Notă:

Please note that the Encapsulated Token is about authentication. It ensures that the cookie can be validated without having to access the repository. However, it is still required that the user exists on all the instances and that the information stored under that user can be accessed by every instance.

For example, if a new user is created on publish instance number one, due to the way the Encapsulated Token works, it will be authenticated successfully on publish number two. If the user does not exist on the second publish instance, the request will still not be successful.

Configuring the Encapsulated Token

There are a few things you need to take into consideration when configuring the Encapsulated Token:

  1. Because of the cryptography involved, all of the instances need to have the same HMAC key. A convenient way to copy the HMAC key to all the instances is to create a package containing the key and install it through package manager on all the instances.
  2. The Encapsulated Token needs to be enabled. This can be done through the Web Console.

Replicating the HMAC key

The HMAC key is present as a binary property of /etc/key in the repository. You can download it separately by pressing the view link next to it:

chlimage_1

In order to create a package that can be used to replicate the key across instances, you need to:

  1. Go to the Package Manager located at: http://serveraddress:port/crx/packmgr/index.jsp

  2. Press the Create Package button.

  3. In the following window, add a name to the package and press OK.

  4. Find the newly created package in the list, and press the Edit button.

  5. Go to the Filters tab and press the Add filter button.

  6. Enter /etc/key in the Root path field and press Save.

  7. Build the package by pressing the Build button. After the package is built, download it locally by pressing the Download button.

  8. Install the package on the other instances in your deployment.

Notă:

For more info, see the page on How to Work With Packages.

Enabling the Encapsulated Token

Once the HMAC key has been replicated, you can enable the Encapsulated Token via the Web Console:

  1. Point your browser to http://serveraddress:port/system/console/configMgr

  2. Look for an entry called Day CRX Token Authentication Handler and click it.

  3. In the following window, tick the Enable encapsulated token support box and press Save.

Această lucrare este oferită sub licență Atribuire-Necomercial-FărăModificări 3.0 Ne-adaptată Creative Commons  Postările pe Twitter™ şi Facebook nu sunt acoperite de condiţiile de licenţiere Creative Commons.

Prevederi legale   |   Politică de confidențialitate online