Home » Blogs » ziptiespec's blog

Utilizing Luminis authentication and SSO capabilities outside of the Portal

Submitted by ziptiespec on Mon, 2010-02-15 22:12

As our school's Luminis go-to guy, I've become involved in a new project (shopping cart system) that does not use Luminis as a platform but will be more successful if we're able to leverage a couple of Luminis' features: authentication and SSO.

First, a little background on our set up.  We're not a Banner school, our ERP system is Datatel.  We're on Luminis 3.3.3.79 which authenticates against it's own internal LDAP.  Luminis handles SSO to many external apps including the web frontend of our ERP, WebAdvisor, where users handle their "business": paying bills, registering for classes, etc.  WebAdvisor is the platform that the new shopping cart system is going to be built upon.  This is important because many/most users don't know their passwords for this system - they only know their Luminis password.

The shopping cart system itself is supposed to improve upon our current instant enrollment process for continuing education/non-credit course.  The goal for this system is to provide a new interface where users can browse/search for courses, add them to a cart, checkout, pay, and therefore be registered.

We want to bring Luminis into play during this process because the Luminis username/password is one that all users know and use frequently so it only makes sense to utilize those for the shopping system as well.  Writing an external app to authenticate using Luminis' LDAP is pretty trivial.  Luminis also comes into play because it already handles SSO to WebAdvisor.  This is not so trivial as a user must be logged into Luminis in order to be able to SSO into another application.

With this shopping system the goal is to do everything outside of Luminis, or at least with the appearance of doing everything outside of Luminis, like so:
 

  1. User arrives at shopping site
  2. User searches for or browses courses
  3. User adds a course to the cart
  4. User is required to log in at this point
  5. Log in occurs using Luminis user/pass.  As part of the log in process the user is transparently "bounced" through Luminis which SSO's the user back into the shopping cart system.
  6. User is then shown costs for the course and can continue shopping or check out.

The reason for having the shopping system outside of Luminis is so that there's no Luminis tabs/navigation/icons/etc. to confuse or distract.

My initial ideas on how to accomplish the above involved modifying the Luminis log-in process.  Add logic to test for the presence of a token (e.g., hidden form field value) to determine whether log in is coming from the shopping cart or not.  If the token was not present, the user would go from log in to the portal (/cp/home/next).  If the token is present, then the user would skip the portal and get sent to /cp/ip/login?sys=NAME&url=null - back to the shopping cart system but as an authenticated user.

I wanted to first find out if any fellow Luminati have thought about or attempted something like this.  I'm also open to any alternative suggestions on how to accomplish this.

In the meantime I'm about to start the process of reverse-engineering the Luminis login.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SSO solutions

Submitted by bsimpson on Tue, 2010-02-16 01:34.

The Luminis Portal is designed to be the starting point for all SSO operations. A user logs into the Portal, and can access email, course registrations, fee payments, etc. The Luminis "secret store" just encrypts the user's password using the user's password in a reversable algorithm, or as a key or something. 

In order to SSO into the Luminis portal, you would just have to make the user supply their credentials in another format or in another location.

We have a couple of methods that simulate these SSO connectors functioning outside of Luminis. We set a domain-wide cookie (".clayton.edu") containing the user's ImmutableID, username, and a token that we then check for in homegrown applications. We make sure that the data all correlates to a single user, and that it is correct, and assume the user is logged in from Luminis. This allows us to SSO straight into applications outside of Luminis anywhere on the domain and sounds like what you are describing. More info here: http://www.lumdev.net/node/2672

Also, I would advise against modifying the Luminis login process. For starters, its a mess, with like 4 redirects. On top of that, its compiled code, and code that is not intended to be modified.

Good luck!

Thanks for the reply, and for

Submitted by ziptiespec on Tue, 2010-02-16 16:56.

Thanks for the reply, and for the info!  The applications that you SSO to outside of Luminis don't sound like they require a user/password combo, just the prescence of the token that you mention - or perhaps I'm mistaken about that?

Why SSO?

Submitted by ToddTrann on Tue, 2010-02-16 11:52.

Why do you need to log them in to Luminis at all?  I must be missing something. 

Sounds like they can conduct all of their business outside of the portal for this set of transactions, all you need to do at the login point is bind to the Luminis LDAP as you say, and log them into the shopping cart application.

Todd

why sso

Submitted by Jason on Tue, 2010-02-16 15:50.

 That was my initial thought.  If the app is intended to be reached from outside of luminis, just bind to ldap and then create a session variable in the app to store the fact that they were successfully authenticated.

I have some coldfusion code examples if you use that language.

Maybe I'm the one missing

Submitted by ziptiespec on Tue, 2010-02-16 19:27.

@Todd and Jason

Maybe I'm the one missing something.  Or maybe I've just been thinking about this the wrong way for too much time.

When I first pondered this issue and picked a modified Luminis login process as the best chance for a solution, I was fresh from installing SunGard's official password reset component.  As part of that installation I modified these settings:

security.login.password.force.successURL
security.login.successURL
security.login.eas.passwordsync.successURL

from: /cps/welcome/loginok.html

to: /cps/welcome/pswdLoginRedirector.html

This new page redirects to a .jsp that checks to see whether a user has answered their security questions.

I thought that I could further utilize this setting to point to a page/script that would contain the login which sends a user either to the portal or back to the shopping cart.

My first attempts at this relied on a hidden form value but I soon discovered that this hidden value never got passed to the page that those configman settings point to.

I began testing a value passed via cookie last night and so far it looks like that may work.

Anyway, my reasons for having them log into Luminis:

  1. The shopping cart application, as currently configured, requires a user/password for log in
  2. The users don't know the password for the shopping cart application.  Username is the same used on Luminis though.
  3. Luminis knows the password for the shopping cart application and currently SSOs to this same platform (via GCF) for other purposes.  We have a "Self Services" tab within the portal that is just a frame containing WebAdvisor.

Again, the shopping cart is going to use Datatel's WebAdvisor as a base (not my perference!) which is a bit of a black box.  Other schools have used CAS for SSO into it though.

I think I understand what you mean about utilizing Luminis LDAP except for that the external system password in the store is hashed and I don't believe that I have access to it in an un-hashed form for comparison.

As for CF examples of this, they'd be great, thank you!

if I get my login redirection based on cookie working, would there be any downside to relying on that rather than what you propose?  Provided the password issue can be addressed.

Thanks for the replies!

shopping cart

Submitted by Jason on Tue, 2010-02-16 20:24.

 I think the piece you are missing is that the plain text password is not needed to authenticate against the ldap.  

Basically authentication from some custom code has a few steps

1.  You bind as the directory manager.
2.  The directory manager takes the typed in username and queries the ldap for the user's DN.
3.  You perform another ldap query, this time, binding as the user DN and the user typed password.
4.  You catch any errors, or otherwise determine if the bind attempt was successful.  
5.  You set a cookie, session variable, or some means of knowing that the user is logged in.

I attached a cfml login script to this blog post: http://www.lumdev.net/node/3446

 

Syndicate content