Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

SSP v2.6.0 General Release Announcement

 

Release November 21, 2014

Release Highlights

  • Add the Watch Student feature
  • Add bulk actions for Caseload and Search Results (IE: email, export, change program status)
  • New Early Alert Reports
  • MyGPS navigation improvements
  • Significant Report fixes
  • All stability improvements and bug fixes included in the v2.5.X releases

 

There are no external database schema changes in this release

Fresh Installation Instructions

See SSP v2.6.0 Installation Instructions

Upgrade Instructions

Upgrading Source Code Forks

See SSP Source Code Upgrade Process

Additional Upgrade Steps

 

It is important to first follow the steps in the Release Notes for v2.5.1 and v2.5.2.

The SSP development team is not aware of any SSP deployments integrated with CAS, but this release includes two security-related patch sets specifically targeted at CAS integrations:

  • SSP-2721 - Scrubs certain CAS-specific request parameters. The changes and effects are detailed in the uPortal project.  No work should be required to enable the patch, but you may want to review that document to better understand the CAS-related configuration changes included in this release.
  • SSP-2724 - Works around what amounts to a CAS-specific session hijacking vulnerability. The changes and effects are detailed in the uPortal project and the <platform-src>/uportal-war/src/main/resources/properties/security.properties file includes greatly expanded comments describing recommended configuration changes. You will likely want to review the email thread and changes to that file whether or not you use CAS. The new defaults may interfere with your existing authentication provider integrations, especially AD/LDAP. SSP-specific details below.

 

1 - Cleanup-up potentially corrupt Maven repo dependencies

SSP-2817 made additional changes to the SSP-Platform ant build script to try to work around continued problems with corrupt Maven dependency downloads. Deployers clean out possibly corrupt dependency downloads before updating SSP and/or Platform build to v2.6.0.  The Maven repo base is where the .M2 directory exists (IE env variable = MAVEN_HOME)

  • Unix/Linux
    • rm -rf <repo-base>/net/sf/ehcache
rm -rf <repo-base>/org/jasig/cas/client
  • Windows
    • delete folder <repo-base>/net/sf/ehcache
    • delete folder <repo-base>/org/jasig/cas/client

2 - Update to java 1.7

Java 1.7 is now required and the only version of java that SSP will use.  Once the code branch has been pulled into the local repository, the Platform API must be built prior to deploying SSP Platform as shown below:

cd <SSP-Platform source>/uportal-java-api
mvn clean install

 

3 - Adjustments to Single Sign-On (SSO) Person Lookup Filtering

  1. This upgrade step ONLY applies to implementers that source person attributes from AD/LDAP AND end users may have more than one entry among all the searchable AD/LDAP branches currently configured in SSP Platform.  There are multiple steps to properly configure the lookup filtering as described below.  

    1. <platform-src>/uportal-war/src/main/resources/properties/contexts/personDirectoryContext.xml - Each LDAP DAO requires a line similar to the following in its resultAttributeMapping map:

      <entry key="distinguishedName"><value>distinguishedName</value></entry>

In all cases the <value> must be 'distinguishedName'. The key might be directory-specific. E.g. in Apache DS, the correct config is:

<entry key="entryDN"><value>distinguishedName</value></entry>



    2. Make distinguishedName visible. Run this command from <platform-src> (all one line) to import the updated permissions:

      SSP_CONFIGDIR=/path/to/ssp/config ant -Dmaven.test.skip=true
-Dfile=uportal-war/src/main/data/ssp_entities/permission_set/Everyone__VIEW_USER_ATTRIBUTE__distinguishedName.permission-set.xml
data-import



    3. <ssp-config-dir>/ssp-platform-config.properties - Specify the filtering strategy as described by comments in <platform-src>/uportal-war/src/main/resources/properties/ssp-platform-config.default.properties.  As noted in those comments, if you choose PreferredBaseDnPersonAttributesFilter or RequiredBaseDnPersonAttributesFilterbe sure to specify the prioritized DN. E.g. for an imaginary and very simple directory.

      # Spring pseudo-URL pointing to a Groovy implementation of IPersonAttributesFilter
# suitable for filtering person directory lookups for end users hitting the
# portal via the /sso API. OOTB options:
#
#   classpath:org/jasig/portal/portlets/lookup/NoOpPersonAttributesFilter.groovy - Default. Does nothing.
#
#   classpath:org/jasig/portal/portlets/lookup/RequiredBaseDnPersonAttributesFilter.groovy - Limits directory search
#      results to only those persons associated with the baseDn configured by an additional property set in this
#      file. E.g. to limit SSO to users in the 'faculty' branch of an imaginary LDAP directory:
#
#        environment.build.sso.personFilteringBaseDn=ou=faculty,o=persondir
#
#      For this to work, personDirectoryContext.xml DAOs must be configured to expose a logical attribute named
#      'distinguishedName'

#   classpath:org/jasig/portal/portlets/lookup/PreferredBaseDnPersonAttributesFilter.groovy - Similar to
#      RequiredBaseDnPersonAttributesFilter but allows results not associated with
#      environment.build.sso.personFilteringBaseDn. I.e. if an end user has multiple directory entries with the same
#      environment.build.sso.personDirectoryUuidAttributeName (see below) and that attribute is being used as the
#      lookup key, choose the entry associated with environment.build.sso.personFilteringBaseDn, if any. Otherwise
#      return all results (which may result in an error downstream). Use this is you want to allow SSO for
#      users in a variety of base DNs, but need a policy for narrowing down entries for certain users.
#
# If none of these strategies work for your deployment, you can define a custom strategy without forking Platform
# source by defining your Groovy-implemented IPersonAttributesFilter anywhere that can be referenced by a Spring
# pseudo-URL. If you define a file: URL, changes to the script will be picked up automatically without requiring
# an app server restart. E.g.:
#
#  environment.build.sso.personFilteringScript=file:/opt/sspconfig/MyPersonAttributesFilter.groovy
#
environment.build.sso.personFilteringScript=classpath:org/jasig/portal/portlets/lookup/NoOpPersonAttributesFilter.groovy

 

4 - Import Permissions for Watch Student Feature

After the SSP-Platform source has been pulled into the local repository, the following import will add the appropriate permissions for the Coach and Manager roles to enable the Watch Student feature.

SSP_CONFIGDIR=</path/to/your/config/dir> ant -Dmaven.test.skip=true -Ddir=uportal-war/src/main/data/ssp_entities/patches-SSP-2-6-0/SSP-770 data-import

 

5 - Import Permissions for Bulk Action Features

After the SSP-Platform source has been pulled into the local repository, the following import will add the appropriate permissions for the Coach, Manager and Administrator roles to execute Bulk Actions from the Caseload and Search Results

SSP_CONFIGDIR=</path/to/your/config/dir> ant -Dmaven.test.skip=true -Ddir=uportal-war/src/main/data/ssp_entities/patches-SSP-2-6-0/SSP-2086 data-import

 

6 - New permissions and functionality were created to remove the Main Tool from individual users or groups/role (added in v2.5.2)

The intent of this feature is to remove the display of protected information from users who should not have access.  For example, the application can be configured such that faculty members who do not need to view academic history for any student will not have the Main Tool available in the UI.  Instructions to manage the permissions are described in the User Guide. Before you'll be able to manage those permissions, though, you need to run the following command from within your SSP-Platform source code checkout (only necessary for an upgrade; fresh installs will execute this file automatically):

Import New Permissions
SSP_CONFIGDIR=</path/to/your/config/dir> ant -Dmaven.test.skip=true -Ddir=uportal-war/src/main/data/ssp_entities/patches-SSP-2-5-2/SSP-2631 data-import

7 - New permissions and functionality to display Student Risk Indicators on the Main Tool (added in v2.6.0)

IMPORTANT- this only applies to situations where individual permissions need to be assigned to a group/user.  By default, the indicators are accessible by any group/user with PERSON_READ.  The intent of this feature is to display student risk factors based on data loaded into the external database table.  SSP will display the indicators defined a active in administration.  Before you'll be able to manage those permissions, though, you need to run the following command from within your SSP-Platform source code checkout (only necessary for an upgrade; fresh installs will execute this file automatically):

Import New Permissions
ant -Dmaven.test.skip=true -Ddir=uportal-war/src/main/data/ssp_entities/patches-SSP-2-6-0/SSP-2898 data-import
ant -Dmaven.test.skip=true -Ddir=uportal-war/src/main/data/ssp_entities/patches-SSP-2-6-0/SSP-2899 data-import

8 -  SSP Platform Database Pool Configuration Options

The database pool configuration options were externalized into the ssp-platform-config.properties files.  All of configuration values were previously included in the source files: datasourceContext.xml and/or rdbm.properties.  Generally, the values were changed to increase the value of environment.build.portaldb.max.active.  Any implementer may wish to back out that change and re-apply it in $SSP_CONFIGDIR/ssp-platform-config.properties. Otherwise, deployers should not be affected by the externalization as all default values were defined in the default configuration.

SSP v2.6.0 JIRA Issues

Bugs

 

Improvements and New Features

 

 

 

 

  • No labels