FileBasedKeyManagerConfiguration.xml revision 20247dd12aa0db33627fdeb398385dd27eb26c2e
<?xml version="1.0" encoding="utf-8"?>
<!--
! CDDL HEADER START
!
! The contents of this file are subject to the terms of the
! Common Development and Distribution License, Version 1.0 only
! (the "License"). You may not use this file except in compliance
! with the License.
!
! You can obtain a copy of the license at
! See the License for the specific language governing permissions
! and limitations under the License.
!
! When distributing Covered Code, include this CDDL HEADER in each
! file and include the License file at
! trunk/opends/resource/legal-notices/OpenDS.LICENSE. If applicable,
! add the following below this CDDL HEADER, with the fields enclosed
! by brackets "[]" replaced with your own identifying information:
! Portions Copyright [yyyy] [name of copyright owner]
!
! CDDL HEADER END
!
!
! Portions Copyright 2007 Sun Microsystems, Inc.
! -->
<adm:managed-object name="file-based-key-manager"
plural-name="file-based-key-managers"
package="org.opends.server.admin.std" extends="key-manager"
xmlns:adm="http://www.opends.org/admin"
xmlns:ldap="http://www.opends.org/admin-ldap">
<adm:TODO>
The key manager must be able to get a pin from somewhere. It looks
in property, then an environment variable, then a file, and finally
in a configuration attribute. At least one must be present. Can we
express this ordering and this "at least one" constraint? Perhaps
support a "one-of" element which can be used to group a set of
properties.
</adm:TODO>
<adm:synopsis>
The
<adm:user-friendly-name />
provider accesses key information in a file on the local filesystem.
Multiple file formats may be supported, depending on the providers
supported by the underlying Java runtime.
</adm:synopsis>
<adm:profile name="ldap">
<ldap:object-class>
<ldap:oid>1.3.6.1.4.1.26027.1.2.20</ldap:oid>
<ldap:name>ds-cfg-file-based-key-manager-provider</ldap:name>
<ldap:superior>ds-cfg-key-manager-provider</ldap:superior>
</ldap:object-class>
</adm:profile>
<adm:property name="key-store-file" mandatory="true">
<adm:TODO>Should use a file-based property definition?</adm:TODO>
<adm:synopsis>
Specifies the path to the file containing the private key
information. It may be an absolute path, or a path that is
relative to the
<adm:product-name />
instance root.
</adm:synopsis>
<adm:description>
Changes to this configuration attribute will take effect the next
time that the key manager is accessed.
</adm:description>
<adm:syntax>
<adm:string />
</adm:syntax>
<adm:profile name="ldap">
<ldap:attribute>
<ldap:oid>1.3.6.1.4.1.26027.1.1.50</ldap:oid>
<ldap:name>ds-cfg-key-store-file</ldap:name>
</ldap:attribute>
</adm:profile>
</adm:property>
<adm:property name="key-store-type">
<adm:TODO>
Can we restrict this to an enumeration? How can the client guess
which values are possible? What is the default value?
</adm:TODO>
<adm:synopsis>
Specifies the format for the data in the key store file.
</adm:synopsis>
<adm:description>
Valid values should always include 'JKS' and 'PKCS12', but
different implementations may allow other values as well. If no
value is provided, then the JVM-default value will be used.
Changes to this configuration attribute will take effect the next
time that the key manager is accessed.
</adm:description>
<adm:default-behavior>
<adm:undefined />
</adm:default-behavior>
<adm:syntax>
<adm:string />
</adm:syntax>
<adm:profile name="ldap">
<ldap:attribute>
<ldap:oid>1.3.6.1.4.1.26027.1.1.55</ldap:oid>
<ldap:name>ds-cfg-key-store-type</ldap:name>
</ldap:attribute>
</adm:profile>
</adm:property>
<adm:property-reference name="key-store-pin" />
<adm:property-reference name="key-store-pin-property" />
<adm:property-reference name="key-store-pin-environment-variable" />
<adm:property-reference name="key-store-pin-file" />
</adm:managed-object>