You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Now as we handled the basics of the JCE and our concepts to enable smartcard based providers we can discuss our manager instances which already implement the most of the logic to create, register and return our providers.

ReaderManager

The ReaderManager is the most important class within our framework. It communicates with the system via the ModuleManager and manages all available readers. It offers different services which are necessary to create a SmartCardAuthProvider. We now should exemplarily go through these services step by step:

  1. First an instance of the ModuleManager interface has to be declared to the ReaderManager. See 3.2 for detailed information of the ModuleManager's tasks. The declaration is executed by calling setModuleManager.
  2. This will lead the ReaderManager to receive the ModuleManagers default module and automatically register it by calling registerNewModule.

Modules are kind of drivers responsible for communicating with a smartcard-reader / smartcard. Each module is able to communicate with a set of smartcard-readers connected to the system. The combination Module / Reader is a unique identifier which lets the ReaderManager know which module it shall use in order to communicate with a reader. Two distinct modules can also share a reader. The ReaderModuleDescription stores this unique identifier and is used by the ReaderManager to address the readers via different modules (drivers).
For each module registered to the ReaderManager a new thread is started which listens to reader events. See 2.4.2 for details about reader events.
A module can be also unregistered by calling unregisterModule. This would stop the module's listening thread and detach all the readers managed by the module. Readers shared with other modules would still be accessible by the other modules.
As soon as a module is registered to the ReaderManager the readers adressed by the module are accessible via the ReaderManager.

  1. Now a module is registerd and the ReaderManager is able to address some readers. Next we can call getSystemReaders which returns us all ReaderModuleDescriptions currently available.
  2. With such a ReaderModuleDescription we can attach a reader by calling attachReader. This call will create a reader instance which is exclisivly reserved and can not be generated a second time. With this reader instance we can create a SmartCardAuthProvider.

We can also detach a reader by calling detachReader. The reader then sends a signal to all its observers that the reader has been detached. The SmartCardAuthProvider listening to that reader then stops operating.



Other features offered by the ReaderManager are:

  • setSystemEventHandler

The systemEventHandler is able to react on reader-added and reader-removed events triggered by the ReaderManager. This function registers the handler at the ReaderManager. The interface is implemented by the SmartCardAuthProviderManager (see 3.3).

  • getDetachedReaders

This function returns all the readers that have not been reserved by attachReader.

  • getAttachedReaders

This function returns all the readers that have been previously reserved by attachReader.

  • unregisterAllModules

This function unregisters all modules currently registered. See 2.)

  • isSmartCardInserted

This function returns wheter a smartcard is inserted for the given ReaderModuleDescription.

  • getFirstAdditionallyReader

Additionally readers can be pre-configured. An additionally reader is a reader which is not directly avaible to the system but may will be accessible in the future such as a e.g. bluetooth reader. So even for those readers which are currently not present providers can be created.
Additionally readers are linked to each module i.e. when two additionally readers are pre-configured and three modules registered there are at least six ReaderModuleDescriptions available at the ReaderManager.
This function returns the very first of it where the order depends on the registration order of the modules and the configuration order of the additionally readers.

ModuleManager / P11ModuleManager

The ModuleManager shall the ModuleManager is an interface be responsible for managing different modules. The instance's tasks are:

  • getDefaultModules

The ModuleManager shall be able to at least return one default module i.e. it shall be shipped with at least one driver able for communicating with smartcard-readers.

  • getDefaultAdditionalReaders

See 3.1 for description of additionally readers. This function shall return the default ones.

  • getDefaultAdditionalReaderInfo

Any reader contains ReaderInfo. In order to support that feature for additional (unconnected) readers this function shall return the ReaderInfo for an additionally reader.

  • registerModule

Readers connected to the system shall be addressable by different modules / drivers. This functions registers a new module and shall enable communication with supported readers.

  • unregisterModule

This function shall (detach and) remove all readers addressable by that module.

  • getRegisteredModule

Shall return all registered modules.

  • getCompatibleReaders

Shall return all readers which are addressable by the given module.

  • existsReader

Shall check whether the reader exists / is addressable.

  • isAdditionallyReader

Shall check whether the reader is an additionally reader.

  • getReaderState

Shall check the state of the reader.

  • getReaderInfo

Shall return the reader info.

  • getModuleInfo

Shall return the module info.

  • getSmartcard

Shall create a smartcard instance.

  • waitForModuleEvent

Shall wait until an event happens like – reader added, reader removed, smartcard inserted into reader, smartcard removed out of reader.
The ModuleManager interface is implemented by the P11ModuleManager which uses the cgPKCS#11 in order to communicate with smartcards. The cgPKCS#11 can be seen as a single module and is used as default module by the P11ModuleManager.

SmartCardAuthProviderManager

The SmartCardAuthProviderManager offers the opportunity to do all the steps 1. – 5. shown in 3.1 automatically. The offered services are:

  • registerSmartCardProvider

A SmartCardAuthProvider is automatically registered to the system. First the provider is created and then registered by Security.addProvider.

  • unregisterSmartCardProvider

First the reader the provider is listening to is detached. Then the provider is unregisted at the system by calling Security.removeProvider. On detach all objects returned by the provider are signaled that the reader was detached. These objects are no more useable. Accessing such an object will fail with an exception.

  • registerAllAvailableProviders

Creates and registers SmartCardAuthProviders for each ReaderModuleDescription which is available and has not been attached in the system.

  • getRegisteredSmartCardProviders

Returns all available SmartCardAuthProviders which where registered by the SmartCardAuthProviderManager. SmartCardAuthProviders created and registered manually are not returned.

  • getAdditionallyRegisteredSmartCardProviders

Returns a subset of providers which are based on additionally readers. This subset is also included in getAdditionallyRegisteredSmartCardProviders

  • getRegisteredSmartCardProvidersWithSmartCardInserted

Returns all SmartCardAuthProviders which are ready to use / have a smartcard inserted.
Furthermore the SmartCardAuthProviderManager implements the SystemEventHandler-interface and selfregisteres as soon as getInstance was called once. Otherwise the SmartCardAuthProviderManager stays uninitialized and does not react on events. at the ReaderManager which makes it capable of receiving reader-added and reader-removed events.

  • onSystemEventReaderAdded

When a new reader is added to the system and the SmartCardAuthProviderManager was called once before a new provider is automatically added to the system.

  • onSystemEventReaderRemoved

When a reader was removed and the SmartCardAuthProviderManager was called once before the provider is unregistered from the system.

  • No labels