Chris, Can you set up Apache to force you to authenticate with CAS before getting to that site? That would let you see if the REMOTE_USER is being set as an environment variable and/or an HTTP header.
If I hit the page with a cURL-like program where I set the REMOTE_USER header, I can see that the page is showing me that the header "remote_user" (case difference) has been set. I am not sure if your script is just lower-casing the header name before displaying it, or if some intermediate proxy is modifying the header. If Cognos relies on a header and it is case sensitive, that could be an issue. $ http GET 'https://test.dcis.hhs.gov/tester/dump.jsp' REMOTE_USER:foo | grep remote_user <li> <b>remote_user=</b>foo</li> Thanks, Carl ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Wednesday, December 3, 2014 12:36:12 PM Subject: RE: [cas-user] Cas for Cognos Carl, We have a script that pulls the env variables. I have been diverted temporarily on another emergency but I'll be back on this tomorrow. You should be able to run this publically although not advertised for environment. https://test.dcis.hhs.gov/tester/dump.jsp Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 -----Original Message----- From: Waldbieser, Carl [mailto:[email protected]] Sent: Wednesday, December 03, 2014 11:06 AM To: [email protected] Subject: Re: [cas-user] Cas for Cognos Chris, You could add something like this to your Apache config to test: RequestHeader set REMOTE_USER %{REMOTE_USER} I *think* that should set the REMOTE_USER *header* to the REMOTE_USER variable Apache is getting ala the Common Gateway Interface. If you have the ability to set up a small CGI site (or Perl, Python, Ruby, PHP, some other scripting language, etc.) on the Apache server, you could create a small site that spits out the REMOTE_USER header and/or environment variable. If you set mod_auth_cas to auth for that site, then you could see what that the values are being passed along how you would expect. Thanks, Carl ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Wednesday, December 3, 2014 10:59:41 AM Subject: RE: [cas-user] Cas for Cognos Carl, Yes, we are aware of that IBM doc as well as many others like it. Funny you say ask IBM. I have. We have a Cognos guy contractor, can’t figure it out. We have IBM support, can’t figure it out either. But you know how support goes. Its hit or miss a lot of times. Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 -----Original Message----- From: Waldbieser, Carl [mailto:[email protected]] Sent: Wednesday, December 03, 2014 10:52 AM To: [email protected] Subject: Re: [cas-user] Cas for Cognos Chris, Is the following relevant documentation for Cognos that you are working with? http://www.ibm.com/developerworks/library/ba-pp-security-cognos_bi_platform-page651/ If so, under the section "Custom Java Authentication Providers (CJAPs)", the docs refer to "the standard HTTP header REMOTE_USER". This is one of the things I always found confusing-- in the Java servelet world, when you use something like AJP, your servlet process gets created with `REMOTE_USER` set as *an environment variable* in the process. It is not an HTTP header, though many docs for different apps refer to it as such. On the other hand, some applications actually *are* looking for an HTTP header, "REMOTE_USER". In that case, you would probably need to have Apache write that HTTP header for you before proxying to your servlet (which could be done using AJP or a normal HTTP proxy). If you have someone you can as at IBM, it would probably be a good idea to verify with them whether Cognos expects an environment variable, or an HTTP header. Thanks, Carl ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Wednesday, December 3, 2014 10:32:28 AM Subject: RE: [cas-user] Cas for Cognos Carl, If I used the string the way you sent it apache said it did not understand String and would not start. I tried using require instead of string but that gave me an error also. Require valid-user we have tried before. Most of what you are doing is very similar but none of seems to work for us. Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 -----Original Message----- From: Waldbieser, Carl [mailto:[email protected]] Sent: Wednesday, December 03, 2014 10:18 AM To: [email protected] Subject: Re: [cas-user] Cas for Cognos Chris, Also, in my Apache config for the site, I have this to proxy the tomcat servlet via AJP: <Proxy *> AddDefaultCharset Off Order deny,allow Allow from all </Proxy> ProxyPass / ajp://localhost:8009/ ProxyPassReverse / ajp://localhost:8009/ <Location / > Authtype CAS require valid-user </Location> The `require valid-user` should be all you need to make sure that CAS authentication took place. I also have the following for configuring mod_auth_cas: LoadModule auth_cas_module /etc/httpd/modules/mod_auth_cas.so CASCookiePath /var/cache/mod_auth_cas/ CASLoginURL https://cas.dev.lafayette.edu/cas/login CASValidateURL https://cas.dev.lafayette.edu/cas/serviceValidate CASRootProxiedAs https://grouper1.dev.lafayette.edu The first line loads the Apache module. The next sets the folder where CAS cookies are stored (make sure permissions are set correctly to let Apache write here!). The next is the login URL of our DEV CAS server. Next is our DEV /serviceValidate URL (our CAS servers are older, but customized to use the CAS attribute release. Your URL is likely different if you are using a more modern CAS-- maybe something like /p3/serviceValidate). Finally, the last directive tells Apache what the `service` parameter for CAS logins ought to look like, because our Apache server is proxied behind Nginx. Thanks, Carl ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Wednesday, December 3, 2014 9:59:43 AM Subject: RE: [cas-user] Cas for Cognos Carl, I'll give it a shot and let you know. Thanks Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 -----Original Message----- From: Waldbieser, Carl [mailto:[email protected]] Sent: Wednesday, December 03, 2014 9:58 AM To: [email protected] Subject: Re: [cas-user] Cas for Cognos Chris, I'm not using Cognos, but we use lots of other Java-based webapps that auth with CAS. For some, like Zimbra, we integrated the Java CAS client directly. For the new pilot we are working on for Internet2 Grouper, we opted for mod_auth_cas. We use Tomcat6 for that particular servlet container. I believe the following line of Java code in the webapp is how the REMOTE_USER variable is pulled into the app: String remoteUser = httpServletRequest.getRemoteUser(); The `remoteUser` variable should contain the user name at that point. Does that help? Thanks, Carl ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Wednesday, December 3, 2014 9:34:18 AM Subject: RE: [cas-user] Cas for Cognos Carl, That is pretty much how we have it set up. I have attached the config files. Are you using Cognos? What we have is a apache server running mod_auth_cas and cognos.conf script alias. The Cognos gateway is on the web server as well. In Cognos.conf if we set ifenv to a specific user, it will log in as that user. Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 -----Original Message----- From: Waldbieser, Carl [mailto:[email protected]] Sent: Wednesday, December 03, 2014 9:24 AM To: [email protected] Subject: Re: [cas-user] Cas for Cognos Chris, So what is your service setup like? I.e. what CAS client are you using? For example, if you are using an Apache front end with mod_auth_cas and you application in a Java servlet container you connect to via AJP, the REMOTE_USER environment variable will be set with the user name in your servlet process. The type of CAS client you use really determines how you access the username when the ticket is validated. Thanks, Carl ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Wednesday, December 3, 2014 9:17:36 AM Subject: RE: [cas-user] Cas for Cognos Carl, Thanks, I guess I misspoke saying passing the password variable. What we need to configure is passing the cookie user information to the remote user variable of Cognos. That’s where we are stuck. Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 -----Original Message----- From: Waldbieser, Carl [mailto:[email protected]] Sent: Tuesday, December 02, 2014 12:52 PM To: [email protected] Subject: Re: [cas-user] Cas for Cognos Chris, The typical scenario is for the user to authenticate with CAS. The credentials are only seen by CAS. CAS responds by issuing a TGC (cookie) that is usable by the CAS server domain (other domains do not see it). If CAS sees the user has a TGC, it issues a ST (service ticket) for the service and redirects the user's browser to the service provider with the ST as a querystring parameter. The CAS client at the service provider, reads the ST, then opens a back-channel HTTPS connection to CAS to validate the ST. There are historically a couple different validation protocols. The modern one is the CASv3 protocol. When CAS validates the ticket successfully, it will respond with the user name, and zero or more attributes (configurable at the CAS server). The attributes can typically be used by the service provider for access control (authorization). The other typical scenario is that the service provider handles access control internally, and bases it purely off the user name returned during ST validation. The user's password is *never* presented to the service provider. That is the whole point of CAS. Authentication is *centralized*. Thanks, Carl ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Tuesday, December 2, 2014 11:49:45 AM Subject: RE: [cas-user] Cas for Cognos Carl, I don’t know what you mean. Once you log into CAS I need it to pass those attributes to Cognos. Otherwise you have to log in twice which defeats the purpose of SSO. What service provider are you talking about. Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 -----Original Message----- From: Waldbieser, Carl [mailto:[email protected]] Sent: Tuesday, December 02, 2014 10:49 AM To: [email protected] Subject: Re: [cas-user] Cas for Cognos Isn't the whole point of CAS so that the service provider *does not get the user credentials*? Thanks, Carl Waldbieser ITS System Programmer Lafayette College ----- Original Message ----- From: "Chris Cheltenham" <[email protected]> To: [email protected] Sent: Tuesday, December 2, 2014 10:20:49 AM Subject: [cas-user] Cas for Cognos Hello All, We are having a hell of a time trying to configure apache to pass the username / password variabkes from the CAS login properties to Cognos. We use a script alias to proxy to CAS form apache web server. Has anyone ever been able to do this successfully? It just a matter of configuring cognos.conf in /etc/httpd/conf.d But we have tried a 1000 different things without success. Thank You, Chris Cheltenham SwainTechs / HHS Cell# 267-586-2369 -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user -- 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/cas-user
