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 3 Current »

SSP v2.5.3 General Release Announcement

 

Released on November 21, 2014. The release is primarily a patch set for bugs identified in v2.5.1 and v2.5.2.  Implementers are strongly encouraged to update to v2.5.3 to correct core functionality in Caseload and Search.

Release Highlights

 

There are no external database schema changes in this release

Fresh Installation Instructions

See SSP v2.5.3 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 - 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


  2. Update the java api in uPortal

    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

SSP v2.5.3 JIRA Issues

Bugs

Improvements and New Features

 

 

 

 

  • No labels