configuration files in ${java.home}/lib/security

[David Schlosnagle]

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 <sean.mullan at oracle.com> 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
>
>