SA1 Deliverable Review Form Identification of the deliverable or milestone Project: EMI Deliverable or milestone identifier: DJRA1.3.1 Title: DJRA1.3.1 – Security Area Work Plan and Status Report Doc. identifier: DJRA1.3.1_v0.4.pdf Author(s): John White Due date: __ Identification of the reviewer Name: Florido Paganelli Affiliation: LU EMI Activity/External project or Institute: SA1 Review date 14/10/2010 Author(s) revision date 22/10/2010 Reviewer acceptance date mm/dd/yyyy Reviewer Replies Notes I will just quote those replies I need to appoint. All the other replies not shown here can be considered ACCEPTED. The document is NOT accepted until the comments here are not replied back. ### General comments The overall document has several critical issues and cannot be submitted this way. Purpose of the document is to state a work plan, hence it is very important to stick to real timeliness. A work plan reviewed on month 6 cannot mention it is a status report at month 3 in its main page. For the sake of correctness and coherence, no backward date should be stated. Main structure with harmonization and evolution is fine, but there is a problem: it's not clear if sections are about Product Teams or Objectives. Some information is missing (Cesnet security product team work plan) and some is wrong, please read detailed comments for suggestions. From an SA1 point of view, that is, keeping in mind the 4 objectives listed in https://twiki.cern.ch/twiki/bin/view/EMI/SA1 and its respective work description, the document should at least give links or resources to show what a system administrator or security administrator has to do when deploying and maintaining each of the existing middleware platforms in order to perform security harmonization and evolution. Observations will be in the Detailed Comments, especially for Argus integration. JW: For a JRA1 work plan it is not correct (or highly speculative) to give deployment and maintenance links/resources. The release anyway deals with these issues in the certification and integration processes. Therefore I will not add this additional material to this document as a fair proportion does not exist.. (Common AuthN libs?) FP: I agree it is not correct to give timelines or resources but security is also a matter of "setups". It should be _at least_ recommended or suggested in this document that documents coping with deployment and release will give best practices for secure deployment and installation and that these practices have to take into account harmonization and evolution processes and have to be agreed and checked with developers of the different stacks. Suggestion is to appoint in chapter 4 Work Plan that: "Middleware stacks developers and security experts shall provide harmonization and evolution security best practices that will be part of SA documents for the same PTs, and therefore they will not be discussed in detail in this work plan." ### Additional recommendations (not affecting the document content, e.g. recommendation for future work) N° Page Section 11 12 4.1.3. VOMS Observations At the end of paragraph 1, change "is now deployed in gLite and ARC" with "can now work together with gLite and ARC" Is Addressed? NO JW: Well the VOMS-SAML version (amything greater than 1.8 I believe) is deployed in gLite and ARC. The fact that the SAML part is not used yet is another issue. FP: The work "deployed" refers to a physical installation or setup of a software or of a piece of code. The SAML profile is just a profile, a document defining rules. Please change it to "is now supported by gLite and ARC" N° Page Section 23 16 4.1.9. Compute area authorization Observations As gLite, UNICORE and ARC maintain user mappings in different places, the Compute Area Authorization Objective should also clearly state whether a standardized user mapping over the 3 stacks will be adopted, or each stack will still be able to maintain its own way of mapping local users to grid users. It is not clear which model is to be chosen as ARGUS, gLite and UNICORE seem to be keeping user mappings into separate security objects while ARC is maintaining this information on each ARC CE. Further discussion on this subject has to be taken into account as it heavily affects how authorization and authentication data is moved from the computing site to the authorization/authentication infrastructure. Is Addressed? NO JW: This is exactly why there is a group following this task. Usage of Argus does not dictate any one mapping method. The ARC rep(s) to the Argus group take care of this subject. FP: Then please add the topic "user mapping" as something this group should investigate. If you think is not right to have it in harmonization, at least put it in evolution.