Get complete control over how custom X.509 certificates map to users in the user registry with the June 2018 beta of WebSphere Liberty. Also, submit usage statistics from your Liberty servers to IBM Cloud Private monitoring services.

Thanks to your support for our regular beta programme, we are able to release new Liberty features every few months. Look out for Liberty 18.0.0.2 coming soon!

In the meantime, check out the 18.0.0.1 release of WebSphere Liberty which is built on the 18.0.0.1 release of Open Liberty. Look out for more betas over the coming months. If you just can’t wait, take a look at the daily builds of Open Liberty.

Follow Open Liberty happenings on @OpenLibertyIO.

What’s new in this beta?

Get it now! Ask a question about the beta

Control how custom X.509 certificates map to users in Liberty’s LDAP and basic user registries

You now have complete control over how certificates are mapped to users in the user registry.

The out-of-the-box X.509 certificate mappers for the LDAP user registry did not handle custom OID’s, parsing of certificate fields and included custom filtering of only a subset of the certificate’s fields. For example, there was no support for Subject Alternative Name (SAN). The out-of-the-box X.509 certificate mapper for the basic user registry only supported using the subject’s cn RDN for the user name. With the X509CertificateMapper API, you can now map a X.509 certificate to a user in the user registry in any way that is required.

Enabling the custom mapping using the BELLs feature

Implement the com.ibm.websphere.security.X509CertificateMapper interface and include it in a JAR. Also include in the JAR a Java ServiceLoader provider configuration file (META-INF/com.ibm.websphere.security.X509CertificateMapper) that contains the fully-qualified class names of any X509CertificateMapper implementations to be used in the Liberty server. Each implementation must be preceded by a comment line containing a key-value pair containing the key x509.certificate.mapper.id and a unique ID as the value. Use this ID to reference the implementation from the server.xml configuration file. Load these implementations into Liberty’s classpath using the bells-1.0 feature and a shared library.

Example configuration file entry:

           # x509.certificate.mapper.id=basicMapper
           com.mycompany.BasicMapper
           # x509.certificate.mapper.id=ldapMapper
           com.mycompany.LdapMapper

Example server.xml configuration for two separate X509CertificateMapper implementations to a basic and LDAP user registry:

          <server>
              <featureManager>
                  <feature>basicRegistry-1.0</feature>
                  <feature>ldapRegistry-3.0</feature>
                  <feature>bells-1.0</feature>
              </featureManager>

              <!--
                      The library contains any X509CertificateMapper implementations.
               -->
              <library id="mylibrary">
                  <file name="${shared.resource.dir}/libs/myLibrary.jar" />
              </library>

              <!--
                      Bundle the library using the BELLS feature.
               -->
              <bell libraryRef="mylibrary" />

              <!--
                      Reference the X509CertificateMapper(s) from the user registries by configuring the
                      certificateMapMode attribute to "CUSTOM" and referencing the ID configured in the
                      provider configuration file in the certificateMapperId attribute.
               -->
              <basicRegistry ... certificateMapMode="CUSTOM" certificateMapperId="basicMapper" />
              <ldapRegistry ... certificateMapMode="CUSTOM" certificateMapperId="ldapMapper" />
          </server>

Enabling the custom mapping with a user feature

Implement the com.ibm.websphere.security.X509CertificateMapper interface and include it in the user feature bundle. Define the X509CertificateMapper implementations as Service Components. The Service Component must specify the x509.certificate.mapper.id property which defines a unique ID as the value. The property can either be specified manually in the Service Component XML file or using the property field of the Component annotation. Load these implementations into Liberty’s classpath with the user feature. Use this ID to reference the implementation from the server.xml configuration file.

Example server.xml configuration for configuring two separate X509CertificateMapper implementations to a basic and LDAP user registry:

          <server>
              <featureManager>
                  <feature>basicRegistry-1.0</feature>
                  <feature>ldapRegistry-3.0</feature>
                  <feature>usr:myFeature-1.0</feature>
              </featureManager>

              <!--
                      Reference the X509CertificateMapper(s) from the user registries by configuring the
                      certificateMapMode attribute to "CUSTOM" and referencing the ID configured in the
                      Service Component in the certificateMapperId attribute.
               -->
              <basicRegistry ... certificateMapMode="CUSTOM" certificateMapperId="basicMapper" />
              <ldapRegistry ... certificateMapMode="CUSTOM" certificateMapperId="ldapMapper" />
          </server>

For more info, see the WebSphere Liberty Knowledge Center docs on Basic registry mapping and LDAP registry mapping.

Submit usage metrics from a Liberty server to IBM Cloud Private

The new usageMetering-1.0 feature adds the capability to register a Liberty server with an IBM Cloud Private metering service and submit usage metrics.

IBM Cloud Private metering enhances the way IBM middleware products can be registered and tracked. It helps track product instances and report usage metrics. Using IBM Cloud Private metering, organizations will have the opportunity to extend and achieve the benefits of cloud environments. For example, IT administrators will be able to register all of their products in a single dashboard, simplifying the management tasks. And capacity planners will be able to right-size their environments based on usage data.

For more info, see the WebSphere Liberty Knowledge Center docs on enabling the metering service for Liberty applications.

What’s already in there?

The May Liberty beta included deploying Spring Boot applications on Liberty (without packaging them as a WAR), bringing your own JSF 2.3 implementation, custom X.509 certificate mapping updates, and customizing the URL path of your OpenAPI docs.

Looking for the latest?

If you’re visiting this post from the future and you’re looking for the latest releases of Liberty, here are the links you’re looking for:

Latest beta release
Latest stable release
Open Liberty downloads

Get it now! Ask a question on Stack Overflow

Join The Discussion

Your email address will not be published. Required fields are marked *