Component Replacement Action	Pros	Cons	Expected Impact	Expected Effort
Trustmanager/Util-Java folded into the Common Authentication Libraries
Replace LCAS/LCMAPS with Argus.
VOMS Service replace by VOMS-Admin
gLExec replaced by sudo and (system) PAM modules
UNICORE Security
UVOS -> VOMS.
ARC Security?

General notes (KB)

First of all I'd like to mention that measuring a removal of what is called a "component" in EMI deliverables/plans is very misleading, inaccurate and hard to achieve. The "EMI components" (at least in case of UNICORE, and I'm not only referring to UNICORE Security PT) are artificial. To provide three examples:

• XACML Entity - until EMI time it was not even a software module. Now it is and after extending it to provide Argus support it has around 1,500 lines of code.
• UVOS - in fact around 13 real software modules well over 50,000 lines of code(!)
• UNICORE Security Libraries - 5 base libraries with very different capabilities.

My point is that even if we made a big, real progress in reduction of code to maintain (measured as number of code lines to maintain) there might be a minimal (if any) progress to report, measured as a removal of whole EMI components. Or we can try to merge some of them, what is a purely artificial and useless work. On the other hand reduction of 2 (small) EMI components may be a way smaller success then a partial reduction of one (big) component.

Therefore IMO the factor that we are reporting should be changed. Reduction of amount of code to maintain sounds as an only one reasonable unit for me.

Trustmanager/Util-Java replaced by the Common Authentication Libraries

Possibilities

New, much better and proper interface, new start to do things properly. Maybe some code from trustmanager, voms and UNICORE can be reused.

Cons

People have to migrate to new code if they use the interfaces directly, but most people in for example Glite use them through axis/tomcat plugins, so migration should be relatively easy. Effort for this is taken from other things. Things work at the moment, so...

Expected Impact

Single codebase to maintain, significant reduction of effort needed, better quality of code expected.

Expected Effort

Noted that significant work will be needed.

Replace LCAS/LCMAPS with Argus.

Possibilities

VT: Possible.

Cons

OK: We must take into account the "local" nature of the installations of LCAS/LCMAPS. ie. These function down to the WN granularity (my words)

Expected Impact

Expected Effort

VOMS Service replace by VOMS-Admin.

Possibilities

AC: Possible that VOMS server goes into maintenance mode VOMS-Admin would still need work to be able to take over though.

Cons

Expected Impact

Expected Effort

gLExec replaced by sudo and (system) PAM modules.

Possibilities

Adding PAM support to gLExec is most probably much less work than substituting gLExec with sudo and configuring sudo in the correct way. Given the recent rewrite of gLExec and the good results of the subsequent vulnerability assessment of gLExec, we think it is no longer a advisable to substitute gLExec by sudo.

JW: This is mentioned in the EMI proposal. Will need to provide some concrete text on this soon. EU review in June.

Cons

gLExec has been reviewed numerous times, we do not know if the same holds for sudo. sudo is hard to configure, while gLExec has over the years been adapted to the specific grid use cases. Improving gLExec to better suit the use-cases is probably easier than configuring sudo (or other tools) to do the same.

Expected Impact

Expected Effort

UNICORE Security

Possibilities

EMI Common Authentication Library should provide a replacement for a quite significant amount of code in some of the libraries contained in this EMI component. Namely crl-checking library should be eliminated completely, additionally amount of code in securityLibrary (client side support) and secutils-xfire (server side) should be reduced.

Cons

Well tested and working code will need to be rewritten.

Expected Impact

New, much better and proper interface, new start to do things properly. Maybe some code from trustmanager, voms and UNICORE can be reused. Additionally more features in case of configuration of trust. Same configuration possibilities and features for UNICORE Gateway and other UNICORE components.

Expected Effort

Moderate.

UVOS -> VOMS.

Possibilities

As UVOS is a very big system (not a component) this task is large. To perform it two we have to ensure full SAML-level interoperability between VOMS and UNICORE (work in progress currently). After this step we are aiming at evaluation of VOMS w.r.t. features offered and used in current UVOS installations (especially PL-Grid installation will be considered). Currently two significant actions are perceived:

• Identification of missing features in VOMS (action on UVOS PT), and their implementation in VOMS (action on VOMS PT). Of course as we can already say that functional differences are large we will have to limit ourself to the most fundamental features - reimplementation of everything provided by UVOS in VOMS is not realistic.
• Implementation of production ready PUSH support for all UNICORE clients. This is partially ready, but needs to be updated, tested with VOMS etc.

Cons

Extremely big effort. Lot of potential integration problems. Less features for UNICORE deployments as VOMS won't implement everything from UVOS.

(JW): Is there a comparison list somewhere of UVOS/VOMS features?

Expected Impact

Significantly less code to maintain, less (hopefully not that much) features for UNICORE deployments using UVOS. Possibility to use AAI features assuming VOMS will support them.

Expected Effort

Extremely big. It is very hard to assess it now as number of issues is hard to be guessed and there is a vast number of other dependencies. To provide one example: discovery of VOMS address by the client requires (at least as I guess) existence of EMI Registry and support for it in UNICORE client.

ARC Security?

Possibilities

For the EMI common Authentication Library, let's first depart the interface into two kinds: certificate manipulating, authentication(communication related). ARC itself includes a library for certificate request generation, certificate signing, and certificate verification, which is similar to the certificate manipulating part of the C++ interface of EMI common Authentication Library. As for the clients side of ARC, including the "arcproxy" (which includes the functionality of grid-proxy, voms-proxy-init, and myproxy-init), "arcsub" (for job submission), and etc., they all use this library. As for the service side of ARC, a piece of code is implemented (by reusing some code of voms project) which is specific for verifying and parsing voms AC. Therefore, for the certificate manipulating part, it is easy to enable the current ARC code to use the C++ interface of EMI common Authentication Library. For the authentication, since the communication part of ARC is implemented as configurable modules, it will not be that easy to replace the current code by the common Authentication Library. The replacement will not need to be in the plan.

Cons

Expected Impact

Expected Effort

-- JohnWhite - 29-Mar-2011

• Security_Condsolidation_v1.pdf: Security_Condsolidation_v1.pdf