How is uPortal CAS security provider version 3 different?
A feature
Login directly to a channel in focus mode
We wanted the feature of being able to give users a URL that would take them directly to a channel. However, interesting channels require users to first log in. So we added code to the LoginServlet to capture a channel functional name. But this broke CAS authentication to the uPortal because the PortalServiceUrl was no longer a constant - it included a dynamic parameter, the functional name of the channel to which the user is to be directed.
A solution
New this version, the preferred approach to CASifying uPortal is to map the CASValidateFilter in front of the uPortal Login servlet. This approach pulls the authentication code out of the SecurityContext implementation itself, making the YaleCasFilteredContext a thin implementation which defers to the work already accomplished by the filter.
This allows the Login servlet to take dynamic parameters, such as the fname of a channel to jump to in focus mode, etc. Previous CAS security provider implementations required that the Portal service URL be statically defined as a constant, through properties files. The CASValidateFilter, however, can accomodate authentication of a Login URL which takes arbitrary dynamic parameters.
CASFilter standardization
By adopting a filtered approach, uPortal can use the same approach that is common for CASifying other Java webapplications, benefitting by the work done to streamline the CASFilter release in recent work on the CAS Java Client package (enhanced error reporting at initialization, e.g.).