Oh CoreID, how I love to hate thee…
Howdy all,
This probably impacts about 4 people world-wide, so I’m probably just documenting here for my notes more than anything else. That said, I’m still working with a customer to finish up their coreID SSO upgrade from 7.x to the 10g release, and it’s been pretty painful. I’m more or less boiling over with hate for computers right now, so none of the witty prose you’ve come to know and love…just the facts. If you find yourself in the market to perform this upgrade soon, here are a few things to keep in mind:
Setup
Several CoreID instances run behind a Big IP Load Balancer. CoreID is the SSO product protecting SSL instances of portal and some other software.
Problem: Intermittent authentication failures
Symptoms:
Users authentication requests to the portal or other SSO protected resources intermittently fail. If you look at the browser headers, you see that failed authentication requests are being incorrectly routed from https://my.portal.server.com to http://my.portal.server.com
Fix: Big IP needs to send a header downstream to the portal and authentication boxes. Specifically, it should send the header:
ProxySSLHeaderVar = OblixSSL
Also, note that you need to configure CoreID to accept/process this parameter. In the 7.x world, this was done in a webgate configuration file named, “webgateStatic.lst”. This file has been deprecated in 10.x, and you need to configure the setting though the Access Manager GUI. Login to Access Manager and find the webgates that are protecting your authentication notes, and your resources. Add a “User Defined Parameter” with the name “ProxySSLHeaderVar” and value “OblixSSL”
Problem: Users can download documents from portal
Symptoms: Users can’t download any documents from the KD or from Collab projects.
Fix: You need to set the cache values on the webgate protecting your portal to public. Again, this used to be done in webgateStatic.lst, but has been moved to the Access Manager GUI in 10.x. Login to Access Manager, find the webgate protecting your portal resource, and set the “CachePragmaHeader” and “CacheControlHeader” values to “public“.
Problem: Notification links into portal don’t work
Symptoms: Links with a query string into portal or other software are getting truncated, with the net result that clicking the links gives users an error. This is only happening when users click link and don’t already have a valid SSO token. URLs are getting truncated like so:
Original
http://myportal.com/gateway/blah/collab?docid=1&projectid=2
Truncated
http://myportal.com/gateway/blah/collab
i.e., you’re losing the whole query string.
Fix: This is a known bug in CoreID 10.x. Call Oracle and get a patch. I’m currently waiting for a callback from Oracle support in which I’ll hopefully get said patch…will let you all know how it turns out.
That about does it for now. Please excuse me while I go break a monitor and/or unleash a steady stream or profanities at my laptop.
I too hate CoreID. I’m assuming the documentation hasn’t improved much with the 10g version?
Brian:
It’s good to have you back on the blog. I can’t help but wonder what your customers think of you wearing a plaid jacket with leather elbow patches. I mean, I’ve not seen you like that, but how could your blog posts about CoreID be so fine without dressing like someone teaching at the Iowa Writers’ Workshop?
Bill
Quick Update:
There is in fact a patch available for the URL truncation problem I mentioned in the post. It’s rolled into a patchset along with a bunch of fixes, and is available as CoreID version 10.1.4.2. In short, if you’re planning an upgrade, just make sure you plan on patching to the latest patch release as part of your upgrade.
Also, @Jordan. I actually don’t think the docs are /that/ horrible for CoreID. It’s just that most implementations have a ton of manual configuration required, and going from docs->production-ready system requires a ton of work.