Software Architecture

Software Architecture

Request handling

Each request that is sent to the SecurityServer is received by the SecurityActor. This class will be initialized at start-up of the SecurityServer with the port configured in the appropriate config file.

Figure: Request handling in SecurityServer

The received message is then analysed based on a message command mapping table. Using a command pattern the specific command will be initialized and executed. The messages that are used here are immutable. This makes it easy to realize non-blocking processing.

Pipeline processing and filters

If the SecurityServer receives a SecurityPipelineMessage, it sends the request to the appropriate command. This message indicates that a mimestream has to be processed in either way. This depends on the properties of the message. The SecurityServer processes this request in a pipeline. This means that based on the configuration that has been sent with the request a pipeline of filters is created. After creation a class call SecurityPipelineProcessor executes it. The filters are process in the order they have been put into the pipeline. A procedure is a kind of functionality like sign, encrypt, decrypt, verify or analyse. Procedures can be combined like sign_encrypt. The diagram below shows some examples of pipelines.

Figure: Building a pipeline

The above pipeline shows a configuration that needs to store the mimestream first and then analyse it. During analysis more filters may be executed based on the mimetype of the mimestream. The second pipeline is a standard request with procedure “sign_encrypt”. The mimestream will first be signed and then encrypted.

Start-up of the SecurityServer

The init process of the SecurityServer runs several tasks that will be explained here. This is important to know since the SecurityServer handles all the actions that have to be executed against the needed keystores. You don´t have to manage this yourself anymore. The SecurityServer always keeps database configuration and keystore in sync!

Abbildung: Initialization phase SecurityServer

First of all the security actor is initiated. This is the main service and realizes the communication over sockets. It also hands over the received messages to the MessageCommandFactory. The second task will create a procedure registry. This is important for the mapping between procedures and filter classes. There are several filters already installed with the SecurityServer. But you can add more if you need them. Using the Plugin Executor external plugins are initialized. Within the init method of these plugins further procedures and filters can be registered. As this plugin mechanism is open, you can change or add the functionality you need. The last step is very important! Certificate and private keys are stored and managed using a database. This makes it easier to handle updates in the configuration. At start-up all private keys and corresponding certificates are loaded into the system keystore. All certificates from partners are loaded into the partner keystores. There are two partner keystores available based on the configuration for usage (sign, encrypt). This makes it easier for the application to handle all the different entries. After the init phase any operation against the database is also synchronized with the keystore!

View Me   Edit Me