Jakarta Authorization configuration

[jhanders34]

For JACC / Jakarta Authorization before 3.0, the com.ibm.wsspi.security.authorzation.jacc.ProviderService SPI is used in Liberty for customers to configure a java.security.Policy and javax/jakarta.security.jacc.PolicyConfigurationFactory. In order to use this SPI, the user provides a user feature that exposes an implementation of this SPI as an OSGI service for the security runtime to find and use. Liberty does not provide its own implementation of PolicyConfigurationFactory and Policy.

In Jakarta Authorization 3.0, the Policy is no longer supported since Policy is deprecated for removal in the JDK. It is replaced by jakarta.security.jacc.PolicyFactory and jakarta.security.jacc.Policy. Also in Authorization 3.0, a way was provided to configure the PolicyConfigurationFactory and PolicyFactory using web.xml configuration. With this mechanism, a user feature can easily use a WAB to provide their PolicyFactory and PolicyConfigurationFactory information in a user feature or in their application.

Originally I thought to maintain the ProviderService SPI, with updating to provide a PolicyFactory or Policy with being passed a contextID, i.e. getPolicyFactory() or getPolicy(String contextId). With the new way of doing things in Jakarta Authorization using a WAB or the user's application, we could remove the ProviderService SPI completely with Jakarta Authorization 3.0 and later releases and have the customer use the new Jakarta Authorization mechanism. Additionally we could provide a default implementation of PolicyConfigurationFactory and PolicyFactory. With the new PrincipalMapper it is easier to provide our own implementation.

SPI Options

1. Keep the SPI class, but update to return jakarta.security.jacc.PolicyFactory or
2. Remove SPI completely in Jakarta Authorization 3.0 feature

Thoughts about each SPI option

1. This option uses the more external way for a customer to configure the Policy information and aligns more with the specification.
2. Since the current SPI cannot be supported any longer because it depends on the JDK's Policy, customers are required to do an update regardless. The use of a WAB or their application uses the new spec way of doing things in the specification, but still allows for a customer to use an user feature.

With option 1, there is also the question of what takes precedence. A user can also provide PolicyFactory and PolicyConfigurationFactory on their application. The setting is global. Currently I think we would have the application one override the ProviderService if we do option 1. If we remove ProviderService this concern is not there.

No matter what we decide, the WAB option will be supported for Jakarta Authorization 3.0, because it is using the spec way you configure your PolicyFactory and PolicyConfigurationFactory, just in a user feature

My preferred option is to do option 2. Not sure if this will require POC approval or not.

Configuration Options

1. Liberty provides their own implementation that is enabled if the appAuthorization-3.0 feature is enabled. This option would satisfy security by default which is not something we provide out of the box for Jakarta Authorization or
2. Still leave it up to the user to provide their own implementation of the PolicyConfigurationFactory and PolicyFactory.

Thoughts about each config option

1. As stated this provides authorization checking out of the box. Customers migrating to Jakarta EE 11, they could see problems if they have authorization configuration in their application and it was being ignored since PolicyConfiguration / Policy was not provided. Customers would need to update their app configuration to remove the config if they do not want authorization checking in reality or update their role configuration if necessary
2. It seems odd that we would not have security by default with the feature enabled.

[abutch3r]

After discussion, the consensus was towards option 2. Given a customer would still have to make changes moving to JACC 3.0 onwards. In addition to WAB loading, the Jakarta Authorization API includes a means to set to PolicyConfigurationFactory which may be better suited to User Features.

Further discussion will happen with Security L2 to see if there is any more information about users of JACC and how they do use it.

Recording: https://ibm.box.com/s/h2mzjv6ho6e8agxg8zwctfcds38yr2mi