RFR: 8348967: Deprecate security permission classes for removal

[David M. Lloyd]

On Fri, 4 Apr 2025 14:12:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > Please review this change to terminally deprecate the following security related permission classes: `java.security.AllPermission`, `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, `javax.security.auth.AuthPermission`, `javax.security.auth.PrivateCredentialPermission`, `javax.security.auth.kerberos.DelegationPermission`, `javax.security.auth.kerberos.ServicePermission`, `com.sun.security.jgss.InquireSecContextPermission`. These classes were only useful in conjunction with the Security Manager, which is no longer supported.
> > 
> > 
> > I agree with most of these, however the permissions infrastructure _itself_ is still used for user-level authorization (at least in WildFly/JBoss middleware, and I would assume other places as well). Part of this infrastructure does rely on `AllPermission` and its `PermissionCollection`. I don't see a reason to deprecate `AllPermission` before deprecating `Permission` itself.
> 
> Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)?

The [`wildfly-elytron`](https://github.com/wildfly-security/wildfly-elytron) project uses `Permission` and `PermissionCollection` as a standalone basic API to represent user authorization permissions. Some examples include `LoginPermission` and `RunAsPrincipalPermission`, and a special `NoPermission` class which is useful in certain situations.

The user authorization mechanism does not use policy files, security manager APIs, `AccessController` or any other JAAS-adjacent API for this purpose.

Security contexts are managed completely separately from the JDK using thread local scoping (planned to move to `ScopedValue` someday if/when it becomes available). Permissions are checked against the user security context (`org.wildfly.security.auth.server.SecurityIdentity`) by authorization-sensitive operations in both server and user code.

The `AllPermission` class is used for "superuser" authorization situations, and cases where the deployer opts out of authorization checks for whatever reason (for example, testing). We use it for role-based access control of the application server itself when access control checks pass, as well for superuser authorization cases, and probably other cases I'm forgetting about (it's one of those things that we always assumed would stick around forever, so we used it without a second thought).

`AllPermission` is an integral concept of permission sets, and thus we would be obliged to create our own if the JDK one disappeared, causing compatibility problems due to the class moving to a new package from the point of view of consumers. Its destiny should be tied to that of `Permission` itself in my opinion, because it is pretty fundamental.

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

PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492