General Security Product Team

This is the "general security PT" that contains components that are either quite "small" or used generally elsewhere throughout the middleware stacks.

Components

• (Trustmanager/Util-java (HIP)) -replaced by common authentication library as of EMI-3

• LCAS/LCMAPS, glexec, SCAS, LCMAPS-plugins-c-pep (NIKHEF)

• Hydra (HIP)

• STS Wiki and Documentation (HIP/SWITCH)

• Delegation Java (HIP)

• SLCS (SWITCH)

• Pseudonymity (HIP/SWITCH/INFN)

Let's wait and see what the AAI for DCIs WS tells for these

Working Groups

EMI JRA1 Security Working Groups:

• Common Authentication Library
• Migration from GSI to SSL

LCAS/LCMAPS EMI 2 packaging changes

• lcas-lcmaps-gt4-interface - moved to ETICS externals
• lcas-interface - produced by emi.sac.lcas
• lcmaps-interface - provided by lcmaps-globus-interface rpm. The original lcmaps-interface is split into lcmaps-basic-interface, lcmaps-openssl-interface and lcmaps-globus-interface. All three are build from the lcmaps src.rpm and hence should build from the emi.sac.lcmaps during mock/pbuilder.

• new plugin location of LCAS and LCMAPS plugins to comply with EPEL and Debian guidelines: ${libdir}/lcas and ${libdir}/lcmaps
• when a relative path is specified for plugin locations it's assumed w.r.t. ${libdir}. When no path is specified, plugin is searched in env vars LCAS_MODULES_DIR or LCMAPS_MODULES_DIR or when unset ${libdir}/lcas and ${libdir}/lcmaps

(mail 10.01.2012): - solution:

• the easiest is to just set a build-time dependency on lcas and/or lcmaps itself
• In a spec file build-time dependencies on lcas-interface & lcmaps-interface should work fine. So in mock builds there should not be any problem.

LCAS/LCMAPS EMI 3 packaging changes

• lcmaps-without-gsi:
  • the etics configuration is the same as for lcmaps itself, so a build-time dependency should be set to emi.sac.lcmaps.
  • In the spec file this should typically be a BuildRequires: lcmaps-without-gsi-devel

Move from java-security to CANL in EMI-3

• the canl-java-tomcat in canl subsystem is the reworked, renamed and moved old trustmanager-tomcat
• the canl-java-axis2 in canl subsystem is the reworked, renamed and moved old trustmanager-axis2
• there is no plan to make a new release of trustmanager* for EMI-3, reusing EMI-2 trustmanager without any changes/repackaging etc can be considered if needed
• Configuration details:
  • For the tomcat integration variables to be used are in: https://github.com/jhahkala/canl-java-tomcat/blob/master/doc/USAGE
  • The axis2 integration uses mostly the same variables, but prefixed with canl: https://github.com/jhahkala/canl-java-axis2/blob/master/doc/USAGE

-- JohnWhite - 02-Jul-2010