Hi Anthony, No, these changes don't currently affect the CAS ClearPass code. The only SecurityContext change I've made is to the context intended for caching the local login password. In part, this is because the ClearPass codebase isn't currently part of uPortal itself.
However, you could certainly use this class change as an example and copy the small change made there to do something similar to encrypt cached CAS credentials in PasswordCachingCasFilteredSecurityContext. One disadvantage to encrypting the password in CAS rather than at the security context would be that you'd need to make sure both CAS and uPortal had matching encryption configurations. Of course, hopefully also the communication between CAS and uPortal should be encrypted by virtue of being done over SSL. Either way, I think you could certainly re-use the new encryption service and CachedPasswordUserInfoService modifications. I'm glad you're looking at the ClearPass code! While it would be wonderful if all applications were always behind a single signon service, I think that project has a lot of potential for helping solve real-world issues (and may be particularly useful for enabling IMAP access). - Jen On Thu, May 21, 2009 at 7:27 PM, Anthony Colebourne < [email protected]> wrote: > Hi, > > +1 support for this. > > While at the conference in Dallas, I discussed with many people about the > CAS ClearPass code. I spoke mainly about the longevity of this codebase, > many people were in support of getting this code to a level where it would > be maintained across such changes. > > Would such a change impact on this code? A feature where password were > encrypted at the CAS end before being transfered into the portal session as > pre-encrypted could benefit this code. > > http://www.ja-sig.org/wiki/display/CAS/Proxying+clear-text+credentials > > Thanks, > Anthony. > > Jen Bourey wrote: > >> Hi all, >> >> I wanted to propose contributing some uPortal enhancements on behalf of >> the University of Chicago. The enhancements improve the existing >> CachePasswordSecurityContext to encrypt the password with a >> Spring-configurable encryption service before storing it in the session. >> We've also updated the CachedPasswordUserInfoService to configurably either >> decrypt the cached password before adding it to a portlet's UserInfoMap, or >> to pass it through in its encrypted form. These changes are intended to >> preserve the ability of uPortal to potentially cache user passwords, while >> ensuring that any passwords present in the user session are encrypted. >> >> Is this a change that we could contribute to the uPortal 3.2-oriented >> trunk? >> >> - Jen >> >> >> -- >> Jen Bourey >> >> -- >> >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > -- Jen Bourey -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
