Version 2 (modified by pjkersha, 15 years ago) (diff)


The Security Services Package

The security services are currently the AttributeAuthority (AA) and the SessionManager (SM), and the latter exploits a MyProxy database. The two outward facing services (AA and SM) have WSDL interfaces. These packages are shown in the adjacent diagram. source:TI12-security/trunk/architecture/uml/securityServices.JPG

Four significant items of work on the SecurityServices are expected under the auspices of DEWS:

  1. The services will be upgraded to ZSI-2.0 (or later). (Required as underpinning work). For related problems, see SecurityIssues.
  2. The WSDL interfaces will be rewritten to take advantage of WS-Security and doc-literal encoding. Note that the former may involve some serious modifications to ZSI if we cannot exploit the  pyGridWare infrastructure (see below). (Required for Standardisation)
  3. The connection between the SessionManager and the MyProxy database will be rewritten so that the SessionManager need only deploy python calls, without any extra infrastructure, thus allowing a simpler installation where the SessionManager is not colocated on the same machine as the MyProxy (which is desirable). (Required for Deployability).
  4. The services will be rewritten to be thread safe, and deployed in an appropriate service environment infrastructure to ensure contending service calls are dealt with efficiently. (Required for Scalability)

source:TI12-security/trunk/architecture/uml/Deployment Model.JPG

Note that ideally the transition to WSDL+WS-Security and WS-SecureConversation should be done using third-party libraries to minimise coding within the project. The main (only?) candidate for this is to use  pyGridWare, however, we have significant reservations about the number of dependencies for this activity and we are also worried about the performance and future of the project. However, it is likely that some of the performance problems will be mitigated by the planned under the hood changes to ZSI XML parsing. We are also concerned that the resulting code should interact gracefully with the java client needed for application developers (discussed below). In practice this may mean the code has to be reverse engineered to work with the IBM-websphere integration of WSDL and WS-Security.