Ricky's Hodgepodge

Today an entry about custom credential stores in wildfly is going to be presented. With the new elytron subsystem the way of securely manage passwords inside the configuration is using a credential store. But what happen if a custom implementation is needed for any reason, is it possible to develop a custom credential store? Yes, it is, and that is the goal of the current post.

1. The first step is downloading, installing and starting the last wildfly server.

   
   wget https://github.com/wildfly/wildfly/releases/download/26.1.1.Final/wildfly-26.1.1.Final.zip
   unzip wildfly-26.1.1.Final.zip
   cd wildfly-26.1.1.Final/bin
   ./add-user.sh -u admin -p admin
   ./standalone.sh
   

2. The credential stores are just provided by a standard JavaSE Provider. So in order to create a custom implementation two classes should be developed.

   • The one that extends the CredentialStoreSpi. This class is the real implementation of the store, with methods like store, retrieve or getAliases to manage the secret values. The standard implementations are placed in this folder and, for example, the MapCredentialStore is a simple Map implementation which is a useful starting point.

   • But the Provider is also needed to register the previous implementation. Inside elytron the provider class is WildFlyElytronCredentialStoreProvider. It adds the services for the standard stores with the correct types, algorithms and implementation classes.

3. For the entry a simple credential store that saves the secrets in a properties file is going to be developed. But to make it a bit more interesting the values in the file are going to be encrypted using a PBE algorithm. The PBE key will be derived from the password passed to the credential store. This point is a bit weak and maybe it was better to use a hardcoded key, but I think that this way the entry is more educational. As always, the implementation is just an example you can extend, improve and adapt to your needs. The full maven project can be downloaded from here and it is also in my personal github account.

   For details in the implementation just check the store class but let's show the provider constructor.

   
       public CustomCredentialStoreProvider() {
           super("CustomCredentialStoreProvider", "0.1", "Custom CredentialStore Provider");
           putService(new Service(this, "CredentialStore", "CustomCredentialStoreProvider",
                   "es.rickyepoderi.ccs.CustomCredentialStore", Collections.emptyList(),
                   Collections.emptyMap()));
       }
   

   The class registers the implementation putting the service with type CredentialStore (it should be this value), algorithm is CustomCredentialStoreProvider (this name will be used later to configure the store inside wildfly) and the implementation class is es.rickyepoderi.ccs.CustomCredentialStore. No aliases or attributes are defined.

4. The final part of the coding process is adding a META-INF/services/java.security.Provider file that will make the JDK automatically detect the provider (ServiceLoader technique).

   
   cat src/main/resources/META-INF/services/java.security.Provider
   es.rickyepoderi.ccs.CustomCredentialStoreProvider
   

5. So we have our custom credential store implementation ready. Just compile it and create the jar.

   
   cd custom-credential-store
   mvn clean package
   

   The final file will be place in the target directory.

6. Now the interesting part, using CLI add the library as a module inside wildfly.

   
   module add --name=es.rickyepoderi.ccs --resources=/path/to/custom-credential-store/target/custom-credential-store-0.0.1.jar --dependencies=org.wildfly.security.elytron
   

7. The provider should be loaded into elytron to make it available to the server (if you remember I did the same with the Bouncy Castle FIPS jars in a previous entry).

   
   /subsystem=elytron/provider-loader=ccs:add(module=es.rickyepoderi.ccs)
   

   As the provider was defined in the service file no more arguments are needed. The provider class will be located automatically.

8. The custom credential can be configured at this point.

   
   /subsystem=elytron/credential-store=ccs:add(providers=ccs, credential-reference={clear-text=XXXXXX}, location=custom.properties, relative-to=jboss.server.config.dir, type=CustomCredentialStoreProvider, create=true)
   

   The type should be CustomCredentialStoreProvider (the algorithm registered inside the provider). The store will use the provided password (please here it is provided in plain which is a nonsense, as I commented this is just an example) to create a PBE key and the values will be encrypted with it. The underlying file is specified using location and relative-to options and placed inside the configuration folder of the server. By default the implementation encrypts values using PBEWithHmacSHA512AndAES_256 algorithm but it can be changed using the implementation-properties option. In general that option can pass custom attributes to the implementation and the example manages several of them you can try and play with.

9. Finally a secret is created inside the store ready to be used.

   
   /subsystem=elytron/credential-store=ccs:add-alias(alias=alias1, secret-value=sa)
   

   And if you check the properties file the alias will be there with the value encrypted.

   
   grep alias1 ../standalone/configuration/custom.properties 
   alias1=oDaesxvoSWLkiwWo89sjzA\=\=\:MFkwOAYJKoZIhvcNAQUMMCsEFGTaNHH+6TJiT6PrGPC/tByEaGIWAgIQAAIBIDAMBggqhkiG9w0CCwUAMB0GCWCGSAFlAwQBKgQQDzqM6mftjvjqCg49J2td7Q\=\=
   

10. That secret will be used to connect to the default H2 datasource that is defined in the wildfly server (that is why the secret value was sa).

    
    batch
    /subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=password)
    /subsystem=datasources/data-source=ExampleDS:write-attribute(name=credential-reference, value={store=ccs, alias=alias1})
    run-batch
    reload
    

    The server should be reloaded OK and the datasource should be able to connect to the H2 database.

    
    /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool
    {
        "outcome" => "success",
        "result" => [true]
    }
    

    It works successfully!

That is all. The entry is a simple example to develop your own credential store. This is usually not needed and standard stores provided by wildfly should be enough for you. But, if for whatever reason, there is a specific requirement that forces you to implement a custom credential store, here you have an example. Remember my implementation uses the password provided to the store to derive a PBE key and encrypt values with it (it was done to show how to recover that password but maybe using a hadcoded key was a better idea). It is just a proof of concept. The entry details the implementation and the configuration of the store inside the server. Links to the maven project were available before, please use it with care.

Best regards!

A very quick personal entry to summarize how to install magisk in my lineage device. It seems that now every time the OS is upgraded magisk should also be re-installed on it. The procedure is described in the project documentation but I prefer my usual detailed steps.

1. Download and install/upgrade the latest magisk app on the phone once it is upgraded.

2. Magisk need to patch the boot.img of the lineage distribution. Download the used lineage bundle for your phone.

3. Install python and the protobuf package on your laptop in order to extract the zip.

   
   dnf install python python-protobuf
   

4. Download extract_android_ota_payload tool and execute it over the zip file.

   
   wget https://raw.githubusercontent.com/cyxx/extract_android_ota_payload/master/extract_android_ota_payload.py
   wget https://raw.githubusercontent.com/cyxx/extract_android_ota_payload/master/update_metadata_pb2.py
   python extract_android_ota_payload.py lineage-18.1-YYYYMMDD-nightly-XXX-signed.zip .
   Extracting 'payload.bin' from OTA file...
   Extracting 'boot.img'
   Extracting 'system.img'
   

5. Use adb to push the image to the phone:

   
   adb push boot.img /sdcard/Download/
   

6. Open the application on the phone, click install, Select and patch File and locate the image. Click Let's go. A patched magisk_patched-XXXXX_XXXXX.img is generated. Copy it to your laptop.

   
   adb pull /sdcard/Download/magisk_patched-XXXXX_XXXXX.img
   

7. Now just flash the new boot image to your phone.

   
   adb reboot-bootloader
   fastboot devices
   fastboot flash boot magisk_patched-XXXXX_XXXXX.img
   

And that is all. Magisk is installed and now my firewall can be configured again.

Regards!

A very quick entry for today. Sometimes the test-containers project (in its java version) is used to add some tests that involve docker in my daily job. The idea is using containers for complicated tests which cannot be easily mocked up and therefore need the full software image. But I have a fedora laptop now and it incorporated podman instead of docker. They are two different container engines, and, although the former was implemented having docker in mind, they are similar but not exactly the same. Therefore the test-containers project needs some tweaks to make it work in my box. Here I am going to summarize the steps that are more or less explained in this issue report.

1. Start the podman service. One of the main difference of podman is that it is daemonless, so we need to start the service in order to have something the test-containers project can talk to.

   
   podman system service -t 0 &
   

2. After that just export some environmental variables to the java project. The unix socket depends on our user (it is not root based) and some features should be disabled from the test-containers because they do not work under podman.

   
   export DOCKER_HOST=unix:///run/user/${UID}/podman/podman.sock
   export TESTCONTAINERS_CHECKS_DISABLE=true
   export TESTCONTAINERS_RYUK_DISABLED=true
   

3. Usually the previous two steps are enough but remember you can specify several things under ~/.config/containers directory. For example the registries you want search images from by default.

   
   cat ~/.config/containers/registries.conf 
   unqualified-search-registries=["docker.io", "quay.io"]
   

That is all. A very short post that I wanted to have in the blog. I am going to need this from time to time. And my memory is very bad for these random things. This way I can always look to this entry and just copy the commands without thinking what they do or why I need them. Sadly the entry will be obsolete soon, but until that moment it will save me a lot of time.

Best regards!