You are here

Storing passwords in Luminis

Submitted by vikram on Tue, 02/16/2010 - 10:54

Have anyone of you done something to ensure that Luminis does not store actual user passwords in the Secret Store anymore? We always have to fight and justify with our Security folks as to why this is a requirement in Luminis. So far we have been using External Authentication with Kerberos.

We have recently tried to use Sungard's Identity Mgmt solution that allows use of an external CAS server (not Luminis's own CAS which I believe still stores passwords) but it has other issues like every single login to Luminis requires a call to Banner which may prove to be catastrophic on high-load days.

We have recently developed our own home-grown solution to use an external CAS to login to Luminis and that will address the password-storage issue and we are currently in the process of testing it extensively before putting it in production. Just wondering if anyone has done something with passwords.

Luminis Version:


I'm very curious about how you're doing the external CAS approach, as we'd really like to get that set up for simliar reasons.

We are currently in the process of migrating from uPortal to Luminis, and our current uPortal setup uses external CAS auth, as per But this approach does not appear to work in Luminis as the CAS client is no longer present.

With regard to storing passwords, we currently we use EAS to auth against our campus LDAP, so the passwords that are in luminis are just bogus filler, and that seems to satisfy our security req'ments.

To use external CAS, you will need to be on Luminis 4.1 or higher. It comes with a cas client, I think it is version 3.0 but that is outdated. We had to install the latest client (3.1.8) from JA-SIG for us to use the serviceValidate class used normally in CAS authentication. The Sungard client relies on bannerValidate which is used for the Identity Management suite.

We are still in the testing phase and once we iron out everything, I will post the steps here.

You mentioned that you are using EAS with your campus LDAP. Did you mean your uPortal or Luminis? As far as I am aware in Luminis, if you use EAS, it saves an encrypted copy of your external password (when you do your first login after account creation or after a password change) in the secret store and uses it in the GCF connectors if you have any. Can you clarify?

I believe you are correct. At least that was my working understanding. I created a custom JAAS module to AD that takes that fact into account (it wouldn't work if that wasn't true).

We are using an external CAS server for single sign-on to address the Luminis password-storage problem as well.

What version of Banner are you on? How are you handling single sign-on to your other applications if you are not storing passwords?  

Virtually every application on our campus uses our campus CAS for authentication. Luminis was the only one that required password storage. Prior to developing our home-grown CAS solution for luminis, we were using a GCF connector to our external CAS server and thereafter single signing on to other campus applications. All this was fine till our campus CAS moved to using CAS3 from CAS2. Form posting was necessary for the GCF to CAS to work. Form posting is allowed in CAS2 but not in CAS3 by default and this necessitated our casifying Luminis with our external CAS server in order to preserve the single sign on capabilities and also to get rid of the password storage issue. Once a CAS service ticket is generated for logging in to Luminis, it can be used to login seamlessly to all other CAS-enabled applications.

We are on Banner 8.2. We have also been able to Casify the Oracle Forms based Internet Native Banner (INB). SSB single sign on can still work with the Sungard middle tier.

I was reading your post about your homegrown setting to enable CAS in your environment, I am curious as of how well did it work in your PROD environment and If you ever got a chance to document and post as you offered. We are in the process to implement a setting just like yours and we are searching information on how other schools have implemented this solution, as there is no CAS documentation in Sunguard other than the integrated CAS.

Any help will be greatly appreciated.


Setting up external CAS for LP4 involves the following:

1. Configman settings:
cas.server.url: your external cas server url
cas.server.proxyCallbackUrl: your external cas server url/manager/proxy/Receptor
cas.client.serverName: Luminis url
cas.client.proxyCallbackUrl: Luminis FQDN your external cas server name
cas.server.port: your external cas server port

2. Web.xml changes
Make the necessary chnages to add the cas server url, servername, service name in the CAS Authentication filter and the CAS Ticket validation filter

3. CAS client setup
Obtain and copy the CAS3 client jar file to your $CP_WEBINF/lib folder. (example cas-client-core-3.1.8.jar). Depending on your CAS filter code and the protocol used, you may need additional jar files (example icu4j-3.4.4.jar and jasypt-1.6.jar) in the WEBINF/lib directory. We use these to invoke the CAs serviceValidate protocol.

4. Create a CAS login filter in com.pipeline.web and then pack it in cp.jar. This is an institution-specific step and will depend on how your external CAS server is setup and what it returns in the authentication payload.

5. Change your luminis login page (login.html and login.jsp as required). You may need to disable the uuid attribute.

Let me know if you have any questions.

Has anyone been able to complete steps 4 or 5 of this? Not really sure what to put into a login filter in cp.jar to make this work.