RFR: 8348967: Deprecate security permission classes for removal

[Daniel Fuchs]

Hi David,

Are there other subclasses of Permission that this framework uses?
More specifically - would it be fine to deprecate NetPermission,
URLPermission and SocketPermission classes?

best regards,

-- daniel

On 04/04/2025 15:51, David M. Lloyd wrote:
>> 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