Hi,
GlassFish internally uses the @Security annotation to set code level security for a small number of services. This is directly based on the SecurityManager machinery, which is deprecated for removal.
It's not used on many services, around 9 or so. For instance:
@Service (name="simpleAuthorization")
@Secure(accessPermissionName = "security/service/authorization/provider/simple")
public class SimpleAuthorizationProviderImpl implements AuthorizationProvider {
// ...
}
The Javadoc is:
/**
* Qualifier used to enable a security check at the point of service injection or lookup.
* Security Services, which are to protected against unqualified injection/look-up, should be annotated as something below
* e.g., @Secure(accessPermissionName = "security/service/<service-type>/<some-specific-name>")
*
* Any caller which injects or looks up the protected security service, the caller's jar/class should be granted the following policy
* e.g.,
* grant codeBase "file:<path>/<to>/<caller-jar>" {
* permission org.glassfish.security.services.common.SecureServiceAccessPermission "security/service/<service-type>/<some-specific-name>";
* };
*
*/
There's a couple of things we can do:
* For GlassFish 7 just remove @Secure. Pull off the band-aid quickly, feel the pain (or not, who really cares about them?) and move on.
* Introduce an explicit parameter to disable the security manager check (disable by default on 7, enable by default on 6) while deprecating for removal @Secure
* For GlassFish 7, decide being enabled or not on whether the SecurityManager is actually enabled or not (I feel that it maybe had to be like that from the start, but alas)
Thoughts?
Kind regards,
Arjan Tijms
