Common configuration
Common configuration
Configuring workers are done by setting properties in the worker configuration. There is one set of configuration options that are handled by the framework, and that applies to all workers, then there are worker specific properties handled by the worker implementation.
Properties are usually defined in the module configuration file used to install a module, or configured manually using one of the bin/signserver.sh setproperty variant.
Setting Authorization Type
SignServer
By default (if the property is not set) is client-certificate authentication required for a signature request to be processed. This can be changed with the AUTHTYPE property.
*** Client certificate authentication ***
AUTHTYPE = CLIENTCERT
(default) requires a certificate of all the clients. The certificates must be in the application server's truststore. Authorized clients is configured manually using the CLI interface.
*** Username/password-based authentication ***
AUTHTYPE = org.signserver.server.UsernamePasswordAuthorizer
USER.[NAME] = [PASSWORD]
USER.[NAME] = [HASHED_PASSWORD]:[HASH_ALGORITHM]
USER.[NAME] = [HASHED_PASSWORD]:[HASH_ALGORITHM]:[SALT]
This authorizer requires a valid username and password. User accounts are configured by setting properties of the form shown above, where [NAME] is the username and [PASSWORD] is the clear-text password. In the second form [HASHED_PASSWORD] should be replaced with the output of the digest algorithm specified in [HASH_ALGORITHM]. The third form uses a hash value that is appended to the password before hashing it.
If a valid username and password is not supplied the worker throws an AuthorizationRequiredException which in case of the HTTP interfaces causes a HTTP Basic Authentication (RFC 2617).
*** Username-based authentication ***
AUTHTYPE = org.signserver.server.UsernameAuthorizer
Form 1: ACCEPT_ALL_USERNAMES = false (default) and usernames are specified:
ACCEPT_ALL_USERNAMES = false
ACCEPT_USERNAMES = user1;user2;user3
Form 2, ACCEPT_ALL_USERNAMES = true and no usernames are specified:
ACCEPT_ALL_USERNAMES = true
An Authorizer that can be used for instance if SignServer sits behind an Apache front-end which uses HTTP basic authentication. With this Authorizer the username is logged but the password is not checked as it is assumed to be checked by the front-end.
The Authorizer can be configured to either accept all usernames or only accept those usernames listed in one of its properties.
*** Remote address authentication ***
AUTHTYPE = org.signserver.server.RemoteAddressAuthorizer
ALLOW_FROM = Comma separated list of IP addresses to allow requests from. By default all other addresses are denied access.
If a worker is invoked directly using an EJB call and no REMOTE_IP is specified in the RequestContext the IP-address is set to the String "null". In that case, to allow requests using EJB calls, null can be added to the list of allowed addresses.
Note: When adding "null" to ALLOW_FROM not only locally running clients like the ClientCLI and AdminGUI is allowed access but also from workers that invoke the other worker directly using an EJB call. This is for instance the case for the XMLValidator which delegates the validation of the certificate to a CertValidator. If the CertValidator had a RemoteAddressAuthorizer allowing access from "null" then the XMLValidator would be able to use it. To restrict users from using the CertValidator (indirectly through the XMLValidator) an Autorizer could be configured for the XMLValidator.
*** DispatchedAuthorizer ***
AUTHTYPE = org.signserver.server.DispatchedAuthorizer
AUTHORIZEALLDISPATCHERS = True, if any Dispatcher should be authorized. (Default: true, currently only true is supported)
Only accepts requests that has gone through a Dispatcher. This Authorizer only checks the present of the DISPATCHER_AUTHORIZED_CLIENT field in the request context to know that the request has passed a Dispatcher.
*** Custom ***
This authorization functionality doesn't work for all use cases. Then it's possible to create a customized authorizer and specify it's class path as value in the AUTHTYPE property. The Processable will then automatically instantiate and use it. How to develop such a plug-in is explained in the developers section.
Archiving Responses
The archiving feature can be used to save all generated responses.
For the OldDatabaseArchiver the Admin CLI can be used to query the archive. See the CLI section for more information.
When a requst has been process each Archiver is called one at the time to archive any results.
ARCHIVERS: Used instead of the old ARCHIVE property to enable archinving by listing the class names of all the Archivers that should be used. Multiple Archivers can be specified separated by a "," (comma character). Exempel:
ARCHIVERS=org.signserver.server.archive.olddbarchiver.OldDatabaseArchiver,org.signserver.server.archive.otherarchiver.OtherArchiver123
ARCHIVE: Previously the archiving was enabled by setting the property to "TRUE". This is the same as to set
ARCHIVERS=org.signserver.server.archive.olddbarchiver.OldDatabaseArchiver
Default: FALSE.
Checking validity of signer certificates
By default the SignServer checks if the signer certificate of a signer is valid before letting the signer process a request. If the signers certificate is not valid an error message is returned. There are two properties that can be set to disable this check:
CHECKCERTVALIDITY: default value is true, meaning that the validity period of the certificate will be verified before processing. Set to false to ignore if the certificate is expired or not yet valid.
CHECKCERTPRIVATEKEYVALIDITY: default value is true, meaning that the validity period in the PrivateKeyUsagePeriod of the certificate will be verified before processing. This is only done if this extension exists (it is optional in a certificate). Set to false to ignore the PrivateKeyUsagePeriod.
MINREMAININGCERTVALIDITY: default value is 0. This property defines a minimum remaining validity time required of the signing certificate. If the signing certificate expires within the number of days specified an error occurs. Set to 0 (default) to disable this check.
Limiting the number of signatures
KEYUSAGELIMIT = Sets how many signatures that are allowed to be created with the same key by this worker (default is -1 = no limit). After the limit has been reached the worker is considered offline. Note that the counter is per key and not per worker so if multiple workers share the same key they will all increment the counter. This also means that the worker is active again after it has gotten a new certificate/key.