Purpose and Focus of Document

The purpose of this document is to collect, analyze, and define high-level needs and features of the NCICB Common Security Module Release 4.1. This document focuses on the functionalities proposed by CSM stakeholders and target users in order to make it a better product.

Vision and Dependencies

Vision or Problem Statement

The 4.1 release of the CSM is proposed to be a follow up release to the December 2007 4.0 release. This release will address integration issues with the CSM and the caGRID products, with the primary focus on Instance Level Security enhancements and enhanced integration between the CSM and the caGRID and caCORE SDK products.

Product Dependencies

This release is dependent on the caCORE components or products documented on the dependencies wiki page (example for caCORE 3.2, https://wiki.nci.nih.gov/x/hIx8).

[Provide additional explanation as applicable. For example, "The EVS vocabulary systems are used by the Java client to retrieve and validate concept information for naming and defining meanings."

Stakeholder, Technical and User Descriptions

Stakeholder Summary

Technical Environment

This product uses the following technical components which have been derived from the current NCICB Technology Stack.

• Client Interface
  • Internet Explorer 6.0 and above
  • Mozilla v. 2.0.0.0 and above
• Application Server
  • Apache Tomcat 5.5.9
• Database Server
  • MySQL 5.0
  • Oracle 9i
• Operating System
  • Windows 2000, XP
  • Unix (Sun Solaris)
• Portable ANSI-SQL compliant relational schemas
• Java 1.5 

Summary of Key Stakeholder or User Needs

The following subsections provide a description of key requirements to address the solution as perceived by the stakeholders and users.

Stakeholder and User Requirements

[High level bulleted list of the requirements; "See below" if all items are GForge entries.] (You may use this section to describe high level features which have more than one corresponding item in the In-Scope Requirements and Enhancements, for example, Improve user interfaces for the caAdapter mapping tools.)

Current Solution to Meeting Needs

The current 4.0 release of the CSM was released in December of 2007.  The 4.0 version can be downloaded at the CSM download site.  The CSM 4.0 version will be supported by the CSM development team during the version 4.1 development lifecycle.

Proposed Solutions to Meeting Needs

The "In-Scope Requirements and Enhancements" describesthe requirements that will be incorporated within the scope of the 4.1 release.  The 4.1 development project will be performed utilizing portions of the Unified Process with a focus on iterative development and releasing dot or beta versions of the software prior to the final release to meet high priority customer needs.

During the duration of the 4.1 development lifecycle the requirements of future development iterations will be evaluated near the end of the current iteration.  The CSM project manager along with the NCICB Product Manager will review already proposed requirements listed in the non-functional requirements section of this document along with the requirements listed in the "Bugs", "Feature Requests", and "External Change Request" Trackers made to the CSM project via the CSM Gforge Web Site (http://gforge.nci.nih.gov/tracker/?group_id=12), the NCICB Core product listservs, or face to face meetings with projects planning to use or already using the CSM.  If an iteration's requirements change as a result of the review mentioned above, the following is expected to occur:

1. This scope document will be updated to reflect the correct scope for the iteration being modified.
2. The "Release Development Items" tracker in Gforge will be updated to reflect the correct scope for the iteration being modified.
3. The task plan must be adjusted to reflect the resources and time needed to perform the work for the updated requirements.

In-Scope Requirements and Enhancements

In-Scope Functional Requirements 4.1

Each new enhancement, modification or new feature is described in detail below.

 Iteration 1 (Approved)

GF#9286 Instance Level Security for Group Level

The Instance level security in the current CSM v4.0 version only supports User level security. The requirement is to also support Instance level security at the group level that allows groups to be considered when performing instance level security. The Administrators can provision groups using UPT and assign users to individual group(s). Many applications associate roles with groups and hence desire Instance level security at group level out of the box. CSM 4.1 release will provide it out of the box and simplify and reduce the efforts involved for respective applications.

Another goal of this requirement is to ensure caGrid compatability for instance level security.  Instance level security within CSM should work with groups defined in the Grid Grouper application.

GForge link

GF#9290 Support Hibernate Annotations

The current CSM 4.0 version implements Instance Level Security at User level by using Hibernate Configuration (HBM) files to determine objects and their associations. The requirement is to support Hibernate Annotations which allows an annotated object model without the HBM files to be utilized by CSM's implementation of Instance level security. More information regarding Hibernate annotations is available at the following location: http://www.hibernate.org/397.html.

GForge link

GF#12231 MySQL subselect performance && Filters

This requirement is to improve performance on MySQL for queries with Subselect and Filters. MySQL had poor performance for sub selects hence existing queries can be modified to increase performance on MySQL by either removing sub selects or reduce their performance impacts as much as possible. The queries formed with CSM's Hibernate filters will be modified to provide increased performance with MySQL.

GForge link

Iteration 2 (Approved)

GF#9288 Not-null=true column un-populatable in MySQL 5.0.45

The requirement is to allow populating not-null=true columns in Join tables. The CSM Schema has certain tables whose objects have getter and setter methods for non-nullable attributes. Certain join tables don't have such getter setter methods for respective objects. Hence the CSM schema will be modified to make such join table columns nullable.

GForge link

GF#10872 LDAPHelper.ldapAuthenticateUser always returns true with blank passwords  

The method in LDAPHelper that ultimately decides whether the provided username/password combination is correct always returns true if the provided password is the empty string.  This is incorrect behavior and a bug. To fix this, the LDAPHelper.ldapAuthenticateUser method will be modified to detect blank passwords and return false or throw  authentication exceptions if needed.

GForge link

GF#14423 Automated Build and Deploy

Work with Build and Deployment Team to enable CSM And CLM Projects to to setup automated build process, setup of a Continuous Integration Server and mentoring on development/build processes.

Build and Deployment Activity

GF#15320 CSM caGrid User Migration Module

Develop a module that will allow applications to convert existing application users that are stored in their local CSM database into Grid users.  The module will also allow applications to, once the user is converted to a Grid user, properly authenticate users and apply the apply the application's existing authorization strategy to the new Grid user.

GF#15321 Attribute Level Security - Strict and Lenient Flag behavior

By default, CSM Instance and Attribute level security denies access to all attributes of an object instance unless User/Group is provisioned to gain access on particular attributes (Strict Behaviour). This new requirement will allow applications to configure Attribute Level Security to enforce Strict Behaviour or Lenient Behaviour. The Lenient Behaviour will allow access to all associations within a Parent and Child objects while securing access to rest of the attributes of an object based on the User Security provisioning done via UPT.

GF#12232 Support @Filter annotations for security filters

By default, CSM Instance and Attribute level security denies access to all attributes of an object instance unless User/Group is provisioned to gain access on particular attributes (Strict Behaviour). This new requirement will allow applications to configure Attribute Level Security to enforce Strict Behaviour or Lenient Behaviour. The Lenient Behaviour will allow access to all associations within a Parent and Child objects while securing access to rest of the attributes of an object based on the User Security provisioning done via UPT.

GF#12233 Consider 'extra-lazy' collection attributes

Hibernate supports the notion of an 'extra-lazy' collection, in addition to lazy and eager fetch modes. Extra lazy collections don't fault the objects when getting the collection size (they issue a count query). caArray found it useful to have group.users be extra lazy to support certain use cases. Recommend that extra-lazy be implemented for this collection, and potentially others.

GF#14574 CSM API Deadlock Issue in MySQL

GF#14574, 14575, 12309 AuthorizationManager Method Updates

Operations will be added to the AuthorizationManager to provide additional robustness for instance level security and other use cases.  Detailed requirements are provided in the associated Gforge trackers.

GF#9291, 9293 Firefox Compatibility for Instance Level Screen

Modifications will be made to address usability issues on the instance level authorization screens.  Detailed requirements are provided in the associated Gforge trackers.

GF#4195,9045,10408 Domain Object Updates

Modifications will be made to the CSM domain objects to address the java usage of the objects, specifically in the areas of serializing and equivalency.  Detailed requirements are provided in the associated Gforge trackers.

GF#14577 Punt artificial primary keys, update_date columns from association table

The tables in question are csm_user_pe, csm_pg_pe, csm_role_privilege, and csm_user_group. These are association mapping tables that represent an association between two entities (ie csm_user_pe represents the set of Users who are owners of a ProtectionElement). Such tables should not have an articial generated primary key. Instead, the pair of foreign keys (again in the case of csm_user_pe that would be protection_element_id and user_id) should be used as the primary key.

The requirement is to also punt the update_date column from these tables as it seems to never actually be set.

GF#12432 Postgres SQL Script Update

Modifications must be made to the Postgres SQL script so that they execute without errors on the versions of MySQL that are on the NCI CBIIT tech stack.

GF#5407 Provide Unlock User option in UPT

Consider providing an option in the UPT to unlock a locked-out user. User who is not locked out and has admin privileges can use the UPT to browse to the locked-out user.

If the user is still locked out, there will be an option to unlock the user.  If a user was locked out, but the prescribed amount of time has elapsed to automatically unlock the user, the unlock option will not be available.

Only users who are actively locked out will have the "unlock" option.

GF#14677 Post Build and Deployment Activity Updates

After the BDA activity, the CSM projects need to be updated with testing framework changes.

• Update JUnits
• Update Database Scripts to enable JUnits.
• Add missing JUnits for CSM API for continuous Integration testing.
• Add JUnits for new functionality
  
  

In-Scope Functional Bug Fixes

Each bug fix included in this release is described in detail below.

GForge number  GForge summary (one label for each item with the text below)

[Brief description of bug]

GForge link

[Estimated level of effort: [LOE]

In-Scope Non-Functional Requirements

This section describes in detail all the non-software related requirements which must be met for this release but do not add functionality. These requirements are included in the scope and project plan due to level of effort or relative importance to the overall success of delivery of the release.

GForge number if applicable Short description of requirement (one label for each item with the text below)

[Brief description of the requirement or activity]. (For example, "Although there are no functional changes to the product for this requirement, the team must migrate the existing software to Hibernate 4.1 to be compatible with the caCORE technology stack.")

GForge link

Estimated level of effort: [LOE]

In-Scope General Support Activities

This section describes in detail all the non-software related activities which must be performed for this release but do not add functionality. These activities are included in the scope and project plan due to level of effort or relative importance to the overall success of delivery of the release. 

GForge number if applicable [Short description of general support activity] (one label for each item with the text below)

[Brief description of the general support activity that is being provided]. (For example, "Level 2 Support, integration of help and training to the user community.")

Out of Scope Requirements and Enhancements

Out of Scope Functional Requirements (Enhancements or New Features)

Items that are out of scope were evaluated as part of the initial scoping activities for this release, and subsequently not included in the final approved scope. These items are also documented in the cumulative backlog of requirements found on the product GForge site.

GForge number  GForge summary description from the tracker (one label for each item with the text below)

[Brief description of feature or enhancement moved from the in-scope section with brief explanation added of why it was not included in this release.]

GForge link

Estimated level of effort: [LOE]

Out of Scope Functional Bug Fixes if Applicable

GForge number GForge summary (one label for each item with the text below)

[Brief description of bug moved from the in-scope section with brief explanation added of why it was not included in this release.]

GForge link

[Estimated level of effort: [LOE]

Out of Scope Non-Functional Requirements

GForge number if applicable [Short description of requirement] (one label for each item with the text below)

[Brief description of the requirement or activity]. (For example, "Although there are no functional changes to the product for this requirement, the team must migrate the existing software to Hibernate 4.1 to be compatible with the caCORE technology stack," moved from the in-scope section with brief explanation added of why it was not included in this release.)

GForge link

Estimated level of effort: [LOE]

Out of Scope General Support Activities

GForge number if applicable [Short description of general support activity] (one label for each item with the text below)

[Brief description of the general support activity that is being provided]. (For example, "Level 2 Support, integration of help and training to the user community," moved from the in-scope section with brief explanation added of why it was not included in this release.)

The CSM team will reserve 25% of 1 FTE to provide support, integration help and training to the user community.

Document History and Project Information