FacebookTwitterLinkedIn
Login / Register

Login / Register

IUG FORUM

Stay always connected!
  1. Jennifer Faist
  2. Sierra/ Millennium/ Encore
  3. Tuesday, September 19 2017, 07:07 PM
  4.  Subscribe via email
We are having a nightmare problem with WAM/SSO for vendors who have switched over to https. We haven’t switched over yet to the wam_sshhost_replace option yet, but we are pretty much up-to-date with our SAN certificate. (There are only a couple of domains missing right now.)

The problem happens when we click on a proxy-rewritten online resource link that redirects to https (or use the EDS search widget which just switched to https and is going through our proxy), the resulting URL redirect information when you login is malformed. It is stripping out the 0-url.vendor.com part of the proxy-rewritten URL causing the browser to misdirect after login to a nonexistent URL on our own server (404 error) or just redirecting back to the home page. Online resource vendors who only use http are working fine. This problem is compounded by the fact that SSO forces users to login even when on campus for https connections despite the service level settings.

These are the vendors that we have found are affected so far:
ProQuest (We have Vogue Archive and Design & Applied Arts Index)
Redbooks
Material Commexion
Statista
Ambrose Video
EDS

We are also seeing the same issue in ScienceDirect and Jstor when you try to login to your personal account and get pushed over into https.

Here is one example to further clarity the situation:
Vogue Archive:
Click on the link:
http://0-search.proquest.com.library.artcenter.edu/vogue/
The login selection screen URL is
http://library.artcenter.edu/screens/ssoauth.html?service=https%3a%2f%2flibrary.artcenter.edu%2fvogue%2f
After logging in you are redirecting to https://library.artcenter.edu/vogue/, a nonexistent page (404 error)
The 0-search.proquest.com part is being stripped out of the service=https part of the URL.

Also, if you compare this to a proxy-rewritten http link from off campus, the URL of the login page is formatted much differently. Here is an example:
Kanopy
http://0-artcenter.kanopystreaming.com.library.artcenter.edu/
The login selection screen URL is
http://library.artcenter.edu/screens/ssoauth.html?service=https%3a%2f%2flibrary.artcenter.edu%2fwamvalidate%3furl%3dhttp%253A%252F%252F0-artcenter.kanopystreaming.com.library.artcenter.edu%253A80%252F
They have %2fwamvalidate%3furl%3 in the URL which is not present in the login screens that follow https links.

Is anyone seeing this same issue, or is it just us?

Right now the workaround is to log into My Account first and then all the https links and the EDS work fine. But that’s not usually the way students work; they search first and then login only when they need to. We’ve put up a message on the home page, but we are also considering redirecting the home page to the patroninfo page to force patrons to login first.

At first we thought this might be related to a recent upgrade after a SSO failure, but the EDS problem predates the migration. It may be that this problem has been there all along and we never saw it because everything was still on http. Now that vendors are moving over this summer to https, we are just beginning to see the problem. It is just a coincidence that the vendors switched over right around the time we had the SSO failure. Also, this is just the tip of the iceberg as far as vendors moving to https. We are receiving notices from many more vendors that are planning to make the conversion. The problem will only get bigger if it is not resolved soon.

Jennifer Faist
Library Systems & Digital Collections Administrator
ArtCenter College of Design

jennifer.faist@artcenter.edu
Comment
There are no comments made yet.
Add Comment
Jennifer Faist Accepted Answer
0
Votes
Undo

UPDATE: It appears that when a user, who is on campus and not logged in, clicks on one of these links that redirects to https, WAM sees they are on campus and determines they don’t need to login so there’s no need to form the wamvalidate part of the URL. They can just get passed straight to the regular proxied URL. SSO then steps in because the user is being redirected to https, and SSO forces logins for https. But the wamvalidate part of the URL was never generated because WAM knew the user was on campus and didn’t need to login on campus, so the destination URL that gets sent to CAS is mangled.

 

After extensive testing, we have determined that setting WAM to force authentication from both on and off campus by changing our verify level in the WAM forward table from 1 to 2 has circumvented the WAM/SSO bug for our Online Resources. So, for each of the following resources that redirect to https, patrons will be asked to login at all locations:

 

Ambrose Video

DAAI

Gnomon Workshop

Material ConneXion

NYT Create an Account

Redbooks

Statista

Vogue Archive

 

Clearing cache, cookies, active logins and site preferences in the browser history is needed to clear the cached login screen with the malformed URL. (DAAI, Statista and Vogue Archive are particularly stubborn in Firefox.)

 

I am a bit concerned that instead of fixing the flaw with WAM/SSO, we are merely circumventing it. This means, that every time a resource switches over to https, I’m going to have to go into the WAM Forward Table to change the verify level to 2. With the forthcoming stricter browser warnings, most vendors are planning to switch to https soon. Also, this means that there will no longer be guest access for these resources for people on campus who don't have a login. This runs counter to our policy of allowing access to our resources for all users who are in the library (i.e. on campus). We have also inconvenienced our users who are used to not having to login on campus and now must go through extra steps to get to the content.


In addition, this workaround
doesn't help with EDS. I can’t really change the verify level to 2 for that one. Our library is open to the public, and we must allow our users to search the catalog without having to have a login. It is working fine on campus as is, but for our off-campus users who do have to login to access content, it is very difficult to explain to them that they must login to My Millennium first before they enter the search term. It just runs counter to the natural path of users. They search for content, and then if they see something they need, then then login. At that point, it’s too late, and they get the HttpHandler error. I thought if we just fixed the proxy bug, it would fix this also, but we’re not fixing the proxy bug; we are just bypassing it. Since we can't use this same solution with EDS, I am looking into removing some entries for EDS from the proxy to see if this fixes the HttpHandler error without causing other issues.

 

We are on Millennium Release 2014 SP4 with SSO v.2 and WAM. If anyone else sees a similar problem, refer III to ticket #579055.

 

Jennifer Faist

Library Systems and Digital Collections Administrator

ArtCenter Library



jennifer.faist@artcenter.edu



jennifer.faist@artcenter.edu
Comment
There are no comments made yet.
Add Comment
  1. more than a month ago
  2. Sierra/ Millennium/ Encore
  3. # 1
Jennifer Faist Accepted Answer
0
Votes
Undo
We are also seeing 401 errors when patrons are not logged in before clicking on the request button for an item, or downloading e-reserves in the course reserves module. Also, online resources that have a starting URL that includes a query string are showing 401 errors from both on and off campus.

jennifer.faist@artcenter.edu
Comment
There are no comments made yet.
Add Comment
  1. more than a month ago
  2. Sierra/ Millennium/ Encore
  3. # 2
Jennifer Faist Accepted Answer
0
Votes
Undo
Innovative has just informed us that the fix for this issue is incorporated into the next release of Millennium 2014 SP6 which is due for general release in June this year.

jennifer.faist@artcenter.edu
Comment
There are no comments made yet.
Add Comment
  • Page :
  • 1


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,pdf,ppt,pptx,doc,docx,xls,xlsx,,txt,rtf,jrxml
• Remove Upload Files (Maximum File Size: 5 MB)
You may insert polls into your post. The poll would then appear in the post.
Vote Options
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.