[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jaspic-dev] Remove usage of permissions
|
Hi,
On Monday, November 29, 2021, Darran Lofthouse <
darran.lofthouse@xxxxxxxxx> wrote:
I assume this is in relation to Jakarta EE 10? I believe the deprecation option fits better with the path that was discussed here:
Maybe this could be a good time to consider why Jakarta Authentication needs / needed these permissions and review this in the specification and APIs.
Yes, so from historical conversations it was essentially because in the olden days the idea was that Ops and Devs were potentially hostile towards each other, even within the same org.
Ops installed the application server and guarded its integrity, while devs would possibly undermine this by their “cowboy software” (the term user back then).
Additionally there was the idea of the application server hosting apps from different customers, which were of course potentially hostile towards each other.
I think we finally came to the conclusion that both models don’t work or that we should not set things up for them.
Especially with container deployments such as Docker Dev the deployment unit is app server + app, so there’s no need to protect against interval hostility there.
Shared hosting php style with a single app server owned by the hoster and one or more apps by external customers also never took off. In practice this was quickly replaced by virtual servers (such as Xen) the here each customer has its own image with their own app server.
Kind regards,
Arjan Tijms
Generally deployments are trusted to define their own authentication requirements so the main protection here is one deployment making changes impacting other deployments or the server as a whole.
Technically using Jakarta Authentication you could have one deployment which has the purpose for managing the other deployments on the server and adjusting the authentication requirements but I don't know if anyone has used these APIs that extensively.
Maybe it would be worth scoping these APIs to the individual deployments allowing them to make their own changes and rely on the scoping to keep them independent.
Regards,
Darran Lofthouse.
Hi,
One thing we haven't discussed historically because it only came up fairly recently, is the removal of the security manager in Java SE for local code-based security checks.
Jakarta Authentication uses a number of them, e.g.
/**
* The SecurityPermission, with name {@link #GET_FACTORY_PERMISSION_NAME}, that is used to authorize access to the
* getFactory method.
*/
public static final SecurityPermission getFactorySecurityPermission = new SecurityPermission(GET_FACTORY_PERMISSION_NAME);
/**
* The SecurityPermission, with name {@link #SET_FACTORY_PERMISSION_NAME}, that is used to authorize access to the
* setFactory method.
*/
public static final SecurityPermission setFactorySecurityPermission = new SecurityPermission(SET_FACTORY_PERMISSION_NAME);
/**
* An instance of the SecurityPermission (with name {@link #PROVIDER_REGISTRATION_PERMISSION_NAME}) for use in
* authorizing access to the update methods of the factory implementation class.
*/
public static final SecurityPermission providerRegistrationSecurityPermission = new SecurityPermission(PROVIDER_REGISTRATION_PERMISSION_NAME);
These are used on the server to check whether the code has code-level permission to set or even get a factory.
Such checks are then carried out by code such as this:
private static void checkPermission(Permission permission) throws SecurityException {
SecurityManager securityManager = System.getSecurityManager();
if (securityManager != null) {
securityManager.checkPermission(permission);
}
}
What shall we do with this?
Options are:
1. Do nothing, ignore the issues until it really breaks (when the type is actually removed from SE)
2. Add an @deprecated javadoc annotation, explaining it will go away (users don't have to do anything, since it's used internally by the API)
3. Just outright remove it
Thoughts?
Kind regards,
Arjan Tijms
jaspic-dev mailing list
jaspic-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jaspic-dev
--
