This section desribes the implementation of html processors and sso authentication in the Desktop Shibboleth module. They are the two most important components of this module.
The Desktop Shibboleth module uses Apache httpclient for http communications. The core buidling blocks of this module are processors. A processor is a class which handles the processing of a single or a group of related html pages. Remember that many interactions in a Shibboleth session are triggerred automatically by a browser. Therefore, processors are designed to be linked and triggered from one to another automcatically. Desktop Shibboleth comes by default with six processors: SPAccessControlProcessor, WAYFProcessor, AutographProcessor, SSOProcessor, AssertConProcessor, and SPTargetProcessor. New processors can be designed and hooked in. Every processor extends the Processor interface, and has to implments to methods: setNextProcessors() and execute(). See the first picture for an example with the SSOProcessor. The execute() method specifies how a html page is processed whereas the setNextProcessors() specifies how processors are chained together.
The second picture illustrates in details the chain among the six processors. It shows how a request originated from the Desktop Shibboleth module travels through different html pages at the SP and IDP side. Such a request often hits the SP Access Control endpoint at the SP in the first step. The Desktop Shibboleth module handles the interaction between the request and the SP Access Control by using a SPAccessControlProcessor. The SPAccessControlProcessor then detects whether it should hand over the request to the WAYFProcessor or the SSOProcessor. If a WAYF is used in the Shibboleth session, the request is handed over to the WAYFProcessor which in turns processes the request and forwards it to the SSOProcessor. The SSOProcessor then sends the request to either an AutographProcessor a directly to an AssertConProcessor and so on. The final request arrives to the target resource and data is processed and returned by an SPTargetProcessor.
In theory, the design of SSO authentication mechanisms is totally up to the IDP administrators. Even though the default authentication shipped with Shibboleth installation is BASIC, an IDP can use customized HTML page with a different backend authentication mechanism for their SSO. This is a challenge for a desktop application which does not want to simulate a browser in every aspect. Initially Desktop Shibboleth provides a tool for auto detecting and parsing SSO html files for the human readable purpose. However, whilst this requires complex processing, it is not the main focus of the tool. Desktop Shibboleth version 2 removes this auto processing and provides a different way to hanlde customized SSO page.
In Desktop Shibboleth version 2, if some IDP uses a customized HTML page for their SSO (such as the OpenIDP Level 2), the user can drop a configuration file IDP_NAME.properties into the config/idp folder where IDP_NAME is the name of the idp. This name must also be added into the idp-list.properties file. The file IDP_NAME.properties describes all the fields required for the customized SSO page. The following is an example for the OpenIDP level 2:
#Number of fields
input.1.display= User Name
input.2.display = Password
The current list of IDP are availabe in idp-list.properties as follows:
#List of idp
idp.list= open-idp-level1 open-idp-level2 \
monash-idp aanet ac3research ammrf auscope anu curtin macquarie melcoe uq