<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Greetings Daniel,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">For the sake of discussion, I will look at these classes as classifiable into two groups: classes that we use (or are useful) only in the context of a security manager, and classes that we use (or are useful) independently of any other JDK API.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I would put all three of these classes (`NetPermission`, `URLPermission`, and `SocketPermission`) in the former category, as well as the other non-`AllPermission` classes listed in Sean's PR: we (and our users) would use them only in the context of a security manager, so when that is gone, our need to support these classes goes with it, as far as I can tell.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The classes that we would continue to require on an ongoing basis (to my knowledge) would include `Permission` itself (obviously), `AllPermission`, and the `BasicPermission` base class (which also seems to be subclassed by many third-party projects).</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Apr 4, 2025 at 10:05 AM Daniel Fuchs <<a href="mailto:daniel.fuchs@oracle.com">daniel.fuchs@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi David,<br>
<br>
Are there other subclasses of Permission that this framework uses?<br>
More specifically - would it be fine to deprecate NetPermission,<br>
URLPermission and SocketPermission classes?<br>
<br>
best regards,<br>
<br>
-- daniel<br>
<br>
On 04/04/2025 15:51, David M. Lloyd wrote:<br>
>> 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)?<br>
> <br>
> The [`wildfly-elytron`](<a href="https://github.com/wildfly-security/wildfly-elytron" rel="noreferrer" target="_blank">https://github.com/wildfly-security/wildfly-elytron</a>) 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.<br>
> <br>
> The user authorization mechanism does not use policy files, security manager APIs, `AccessController` or any other JAAS-adjacent API for this purpose.<br>
> <br>
> 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.<br>
> <br>
> 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).<br>
> <br>
> `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.<br>
> <br>
> -------------<br>
> <br>
> PR Comment: <a href="https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492" rel="noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/24445#issuecomment-2778956492</a><br>
<br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>