In my experience, altering the enabled security providers and
precedence have been the primary reason for modifications and
overrides of the ${JAVA_HOME}/lib/security/java.security file.
Typically this has been in the context of removing unnecessary
providers, as well as restricting algorithms and key sizes that do not
conform to a given set of security requirements (e.g. FIPS 140-2, NIST
800-57 and 800-131A). On one occasion I did need to alter the
login.configuration.provider property to use a custom implementation
of javax.security.auth.login.Configuration to work around issues with
a specific application server on certain platforms.- Dave On Tue, Oct 16, 2012 at 1:45 PM, Sean Mullan <[email protected]> wrote: > On 10/16/2012 09:55 AM, Alan Bateman wrote: >> >> As part of preparing for modules in the future [1], we need to look at >> configuration (and other) files in the JDK and see whether such files >> could eventually move to module-private locations. >> >> There are several files in ${java.home}/lib/security and I'm trying to >> get a feel for how common it is for developers or customers to edit >> them. The specification for java.security.Policy and >> java.security.KeyStore define the name/location of java.security and we >> need to decide whether these can be changed to non-normative references. >> I know from discussion with Sean on jigsaw-dev and elsewhere that some >> customers may change the preference order of providers but this is >> something that needs to be re-examined anyway as part of deploying >> security providers as service providers. I'm mostly interested in the >> other settings at this time and whether it is common or not to change >> them. Also the other files, including java.policy. I realize we might >> not have actual data but as such files are in the JDK image then I could >> imagine it being problematic when upgrading the JDK. > > > Right, any modifications that are made to these files will be overwritten > when you upgrade. There is a way to avoid doing that by specifying an > alternate java.security file using the java.security.properties system > property, or alternatively you can use the java.security.Security API to > override the values of these properties, but unlike system properties I > don't think you can set them via the java command line. > > I have no real data, but I suspect the re-adjusting or adding new providers > is probably the most common use case. The other properties are more obscure > and use reasonable default values. For cacerts and java.policy, the same JDK > upgrade issue applies and will clobber any changes you make, but if you are > using Oracle's deployment tools, you can add new root certs and make system > policy changes using deployment-specific files, so this is less of an issue. > > It might be worth asking the EE folks whether they change any of these > properties. > > --Sean > > >> >> Thanks, >> >> -Alan. >> >> [1] http://openjdk.java.net/jeps/162 > >
