RFR: 8315487: Security Providers Filter [v13]

[Martin Balao]

On Mon, 2 Dec 2024 00:37:45 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Undo SunNativeProvider provider changes. They will be implemented in JDK-8345221.
>
> Thank you for the response, but I'm not sure I get all of your points.
> 
> On Sat, Nov 30, 2024 at 11:04 PM Martin Balao Alonso <
> ***@***.***> wrote:
> 
>> Hi @XueleiFan <https://github.com/XueleiFan> ,
>>
>> Looks to me that this is a significant change compared to what we proposed
>> and would require a heavier specification.  I am not seeing a compelling
>> argument at the moment.
>>
> Sorry if it will be a significant change of the proposal.  But it is the
> case for review, right?
> 
> My first concern is not so much the work that would be required now but the
>> burden of maintaining these APIs in the future if it turns out to be a low
>> demand for them, a marginal benefit or both.
>>
> Yes, I am on your side on this point.  That's also the reason why I am here.
> 
> 
>> While the decision of introducing a built-in filter requires a new
>> system/security property that will need to be maintained, it's not
>> incompatible with a more powerful, extensible and pluggable API in the
>> future. We will not be with our hands tied in that sense. If we introduce a
>> pluggable API, that is a stronger commitment.
>>
> I see it differently.  This proposal impacts the compatibility for future
> introduction of pluggable APIs.  Any new APIs for similar purposes have to
> consider the impact of this proposal, implementation and deployment.   If
> we have a goal, it would be nice to do it right at the beginning,
> especially if the extensible and pluggable API solution is more simple and
> more powerful.
> 
>> The idea of a pluggable core security component looks to me like a door
>> open for different filtering criteria and potential risk of confusion. I
>> see the filter more like a simple firewall with a clear and single
>> specification, that does not leave any room for intepretation or
>> differences in implementation. This core component builds on top of a well
>> defined and unambiguous concept: services are defined as a combination of a
>> provider, service type and algorithm (*).
>>
> I'm not sure how it is possible, or how it is only possible with your
> current proposal.  If I get it right, the filter will not appear in the
> default Java security, and it allows people to edit it.   When you allow
> people to edit it, it is already a public API.  I did not see the point
> about "does not leave any room for interpretation or differences in
> implementation".  The security property is editable.  If it is the goal of
> yours, does the following an alternative proposal looks right, which also
> update java.security file:
> java.s...

Hi @XueleiFan,

Thanks for elaborating more on your proposal. Just to clarify, we appreciate and encourage all sort of ideas in the interest of a better solution, even if they imply significant change and require a heavier specification. By pointing that out in my previous comment, I had the intention to start a technical discussion and see if we find a compelling argument to take that path. Had it been something minor, we could have incorporated it to the proposal without further discussion.

With that said, and having read your last comments, I still have concerns about the proposed change that will try to explain.

It's true that the built-in filter is a public API that defines a syntax that we will need to maintain and potentially extend in a backward-compatible way. A pluggable filter does not replace this API-requirement but adds on top. It's not the property value itself but the interface and hook points that we will need to document and support for (now) filter developers. Pluggable filters will access in principle the same information as the built-in filter (provider name, service type and algorithm) and in the same places (hook points). The idea of hook points and access decisions made by an external component reminds me in a way of the pluggable aspect of the Security Manager architecture. A pluggable filter can walk a call stack to learn a little more about the context but this does not say much about the use for a service SPI instance —e.g. a service will probably be filtered after ::putService—. From this perspective, what is their additional value? I agree that it opens a door. 
 I struggle to see is how it can be more simple, powerful and what are the actual requirements that compensate the burden of supporting this open door from now on. We all probably agree in that once a door is open and there is a community of external producers and consumers, it's difficult to go back. If it is worth having it, I'm all in. If there is something that a pluggable filter can theoretically do that the built-in can not, I'd like to know what it is and enhance it. Having a whole ecosystem of filters with different capabilities may not contribute to a single and robust solution, and may be evidence of a poor built-in filter design and implementation.

The risk of inconsistency is inheritant to additional complexity and interaction between more components, including external ones. For example, a criteria will need to be defined and specified to address the problem of how a pluggable filter interacts with a built-in one. To name a few possibilities, the interface can try to prevent both from being set, but also an error can be thrown if both filters are defined —e.g. one statically and the other with ::setProperty—, one filter can invalidate the other if both are defined, one filter can apply on top of the other with a pre-established order, filters can cooperate conservatively so services need to pass both, etc. With the current proposal, there is a single firewall-like rule applied that can be seen in the configuration itself. With pluggable filters, the behavior will depend on a specific implementation and (potentially) and external configuration. E.g. are we going to have different syntax depending on the 3rd-party filter im
 plementor? Do we need to analyze and compare each 3rd-party filter option to understand how one filter can apply some criteria and some other a different one?

The problems of filtering by algorithm parameters and by use (e.g. MD5 for UUID) are not easy to solve, will require further discussion and are orthogonal to a pluggable filter. The built-in filter can be extended if we come to the conclusion that we hit the limits of a pattern-matching language and there are actions that we cannot express. With a better understanding of the problem, we may want to narrow the door we open (e.g. @franferrax suggested pattern-matching in the context of a built-in filter rule). The idea that filter by use is doable with a pluggable filter is not taking into account that there won't be hook points for that unless we add them. Adding them will make us incur in critical-path costs —same as if they were part of the built-in filter—. But then, if that's what we want, why not adding it to the built-in filter?

getService/getServices API overrides are supported since the initial PR. Please check the JEP and implementation, and let us know if you see any flaw.

Regards,
Martin.-

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2512839417