Adobe recently released its innovative AEM as a Cloud Service. While there aren’t many changes on the development side[1], the underlying infrastructure and the way in which it operates is fundamentally different. Unlike the old service, the cloud-native AEM runs on docker containers on k8s. Because of this changed server topology, the way in which the AC tool is triggered in the cloud has been completely rethought.
With AEM as a Cloud Service, the traditional way to use an Install Hook on the content package containing the yaml files no longer works. With the new service, there is no package installation onto existing instances. Instead, immutable containers are built from scratch using the Sling Feature Model [2]. Those immutable containers only contain the paths /apps and /libs using the Jackrabbit Oak Composite NodeStore [3].
With the Composite NodeStore, the paths /apps and /libs are read-only when running against actual content. Because of this, the AC Tool has to run once when /apps and /libs are created (during creation of the container) and once when the container is started against the actual content of an instance. As part of the new system, a Startup Hook has been introduced that triggers the AC Tool on startup. The startup hook runs on start level 27 (the stage when all packages are deployed), just before the system’s ready checks report that the instance is ready:
For further information about the Startup Hook, see the documentation [4].
With AEM as a Cloud Service, the Apache Felix system console is not directly available but wrapped in a read-only developer console (currently, this cannot contain custom functionality and runs on its own node). To make the AC Tool accessible in the Cloud, a new Touch UI interface has been created:
While the change outlined in [1] might require some alterations in your application, to leverage the AC Tool you just need to upgrade to the latest version (2.5.1 [5] at the time of writing). However, it’s important to note that if you previously installed the AC Tool manually, you’ll need to ensure that you’ve included the AC tool in a third-party package in your software. (In non-cloud systems, this is usually already set-up.)
For local development with the SDK we recommend that you leave the package install hook in. (This is also good practice as it means keeping a package dependency from the config package with the AC Tool software package). With this setup locally the package install hook will run. In the Cloud, the startup hook will become active automatically without additional configuration.
In most cases, if you are migrating to AEMaaCS, you’ll want to use Adobe IMS. It’s easy to reference Adobe IMS groups with the “isMemberOf” property of ACE definitions in your yaml files. IMS groups are created per environment and assignments can be made based on the AEMaaCS runmodes “dev“, “stage“ and “prod“.
References
[2] https://sling.apache.org/documentation/development/feature-model.html
[3] https://jackrabbit.apache.org/oak/docs/nodestore/compositens.html
[5] https://github.com/Netcentric/accesscontroltool/releases/tag/2.5.1