Setting up Alfresco Content Services with docker-compose is really fast and easy. Run docker-compose up and away you go.
But, what if you need to have Kerberos SSO enabled as well?
Read on to discover how to setup Kerberos SSO when using docker-compose.
Note: The docker-compose deployment method is only supported for PoC, demos, and testing scenarios (at the time of writing). You should not use docker-compose for production environment.
This post doesn’t cover setting up a KDC, for example Microsoft AD.
If you wanted to save some time and have Microsoft AD setup for you, have a look at my Vagrant_Machines github Repo. The benifit of using a vagrant AD machine is that you can always redeploy both the AD machine and the docker-compose images to get back to a working environment with a single command.
The complete code for this post can be found here.
Here is my environment configuration:
Microsoft Domain Controller: dc01.example.com
Domain name: example.com
ACS server: acs1
Kerberos User Account: acs1
The high level steps are:
Create environment specific files:
Create two Dockerfile’s, one for Alfresco-Content-Repository, and one for Alfresco-Share
Configure docker-compose.yml to build and use the Dockerfile’s from step 2 (you can replace this with building containers using docker if you prefer)
Run docker-compose up --build
In the bellow directory structure you can see that each custom docker image is created within it’s own sub directory. One for Repository and one for Share.
Let’s jump in and create the environment specific files, I've purposely linked to the file on my github repo rather then copy and paste the content to keep the post a bit more concise and easy to follow
Environment Specific Files
In the project structure above, all the files specific to the custom images are contianed within config/<IMAGE_NAME>/kerberos_files. Any modifications to the names or structure of the above project will likely require a corresponding change in the the custom images Dockerfile.
As the Repository and Share web applications will be running from the same server, acs1 in my case, you can reuse the same keytab file when building the custom images. For clarity, I renamed the keytab file to reflect they are being used in different containers, which is why you see keytab.alfresco and keytab.share in each image's kerberos_files directory.
Using the above environment configuration parameters, I created my keytab file using the following command (^ is the Powershell equvialent of \ in a bash shell):
Take note of the following when you run the command as you will need them later on
Kerberos REALM name: EXAMPLE.COM
If you are deploying Microsoft AD using my Vagrant machine, you will find a keytab file is created for you automatically. Check out how to make this work for your ACS server here.
The offical configuration for the java.login.config file can be found here.
In my setup, I created two slightly different java.login.config files, one for the custom Alfresco Repository Image and one for the custom Share Image. This isn't strictly mandatory as you can reuse the same file for each docker image, with the obvious concern that the Alfresco Repository Container does not need a ShareHTTP JAAS configuration section.
We create a krb5.conf file using the information collected while creating a keytab and from the Environment Configuration. As the custom Alfresco Repository Image and custom Share Image will use the same Kerberos configuraiton, the files in each image's build is exsactly the same.
Note: The realm name EXAMPLE.COM, this must be CAPITALISED. In the below, I directly reference my domain controller dc01.example.com.
As we are using docker containers for Share, we need make sure we change any links that point to a repository api from localhost to the Alfresco Repository Container's. The quickest way I found to do this is by taking a stock share-config-custom.xml file and performing a find and replace for the string localhost, replacing with the name of the repository docker service name.
There are some additional sets listed on the official documentation that must be followed, for example, enabling and configuring the Kerberos section and uncommenting some sections.
We now need to create our custom images which will inject the files we have created. As the Repository and Share are running in different containers, we will need each to have it’s own Dockerfile. This does require a bit docker wizardry, but nothing too complex.
The key points to note are:
The files are copied using a relative path, so make sure you run docker-compose from the docker-compose directory,
krb5-workstation is installed using yum,
Rather then create a new java.security file, the existing one is appended to.
For the most part, the Dockerfile used for our custom Share image is much the same, the only additional step is that we must copy in our share-config-custom.xml file as per the line here.
There are many ways to do this part. You could for example create your docker images with docker first and then specify these images within docker-compose. For simplicity, I am building my images using docker-compose. As mentioned above, this is only intended for setting up a test or demo environment.
The following lines have been added to the docker-compose.yml file to allow docker-compose to build images from our Dockerfiles. (the paths are relative so make sure you run docker-compose from the docker-compose directory):
We must also setup configuration for ldap sync properties and Kerberos properties on the repository service. In my lab I’ve used the following additional Java properties to configure both ldap sync and Kerberos (make sure you adjust these for your environment):