Our environment details are - Apache 2.2.3, Shibboleth 2.5, J2ee version 2.4
(for backend application running on Tomcat 6.0).
I have just switched from mod_jk to mod_proxy_http, as shown in the below
Apache Vhost configuration.
<VirtualHost 11.22.33.93:443>
ServerName https://dev.infosys.com:443<https://dev.infosys.com/>
SSLEngine on
SSLProxyEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "/etc/pki/tls/certs/localhost.crt"
SSLCertificateKeyFile "/etc/pki/tls/private/localhost.key"
RewriteEngine on
# Disabling Track and Trace
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
UseCanonicalName on
ProxyRequests off
ProxyPreserveHost On
# --------------------------------------------
# START : CAS related configurations
# --------------------------------------------
ProxyPass /cas balancer://cas-cluster/cas
stickysession=JSESSIONID lbmethod=bytraffic nofailover=On
ProxyPass /cas/* balancer://cas-cluster/cas/*
stickysession=JSESSIONID lbmethod=bytraffic nofailover=On
<Proxy balancer://cas-cluster>
Order deny,allow
Allow from all
BalancerMember http://11.22.33.93:8080<http://11.22.33.93:8080/>
</Proxy>
# --------------------------------------------
# END : CAS related configurations
# --------------------------------------------
Redirect seeother /ricohentity
https://dev.infosys.com/ricohsp.sso/Metadata
<LocationMatch /cas/login>
AuthType shibboleth
ShibRequireSession On
ShibUseEnvironment On
ShibExportAssertion On
#ShibUseHeaders On
require valid-user
</LocationMatch>
ProxyPass /ricohsp.sso !
ProxyPassReverse /ricohsp.sso !
<Proxy balancer://rworld-cluster>
Order deny,allow
Allow from all
BalancerMember
http://11.22.33.76:9011<http://11.22.33.76:9011/> route=allDevNode1 keepalive=On
</Proxy>
ProxyPass /allDev balancer://rworld-cluster/allDev
stickysession=JSESSIONID lbmethod=bytraffic nofailover=On
ProxyPass /allDev/* balancer://rworld-cluster/allDev/*
stickysession=JSESSIONID lbmethod=bytraffic nofailover=On
</VirtualHost>
While testing, the Shibboleth-SP attributes as well as REMOTE_USER are NOT
available to the Tomcat-hosted J2ee application (backend). In
short,request.getRemoteUser() returns NULL.
request.getAttribute("shibattr-email") returns NULL too.
Please note that the values for the mentioned parameters are coming fine, if
the "mod_jk" settings were used (as shown below in the vhost and worker configs
respectively).
<VirtualHost 11.22.33.93:443>
ServerName https://dev.infosys.com:443<https://dev.infosys.com/>
SSLEngine on
SSLProxyEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "/etc/pki/tls/certs/localhost.crt"
SSLCertificateKeyFile "/etc/pki/tls/private/localhost.key"
RewriteEngine on
# Disabling Track and Trace
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
UseCanonicalName on
ProxyRequests off
ProxyPreserveHost On
# Mount point - Apache load-balancer for Central Authnentication Service
(CAS)
JkMount /cas casLB
JkMount /cas/* casLB
# --------------------------------------------
# START : Shibboleth-SP related configurations
# --------------------------------------------
Redirect seeother /ricohentity
https://dev.infosys.com/ricohsp.sso/Metadata
<LocationMatch /cas/login>
AuthType shibboleth
ShibRequireSession On
ShibUseEnvironment On
ShibExportAssertion On
ShibUseHeaders On
Require valid-user
</LocationMatch>
JkEnvVar shibattr-NameID ThisIsDefaultValue
JkEnvVar REMOTE_USER ThisIsDefaultValue
JkEnvVar shibattr-userId ThisIsDefaultValue
JkEnvVar shibattr-firstName ThisIsDefaultValue
JkEnvVar shibattr-lastName ThisIsDefaultValue
JkEnvVar shibattr-email ThisIsDefaultValue
JkEnvVar shibattr-userName ThisIsDefaultValue
# --------------------------------------------
# END : Shibboleth-SP related configurations
# --------------------------------------------
JkUnMount /ricohsp.sso/* allDevLB
JKMount /allDev allDevLB
JKMount /allDev/* allDevLB
</VirtualHost>
worker.list=cas-node1,allDev-node1
worker.cas-node1.port=8009
worker.cas-node1.host=10.66.176.93
worker.cas-node1.type=ajp13
worker.cas-node1.connect_timeout=60000
worker.cas-node1.prepost_timeout=60000
worker.cas-node1.socket_timeout=60
worker.cas-node1.connection_pool_timeout=60
worker.allDev-node1.port=8011
worker.allDev-node1.host=10.66.176.76
worker.allDev-node1.type=ajp13
worker.allDev-node1.connect_timeout=60000
worker.allDev-node1.prepost_timeout=60000
worker.allDev-node1.socket_timeout=60
worker.allDev-node1.connection_pool_timeout=60
So far, with mod_proxy_http configurations, the Shibboleth-SP attributes as
well as REMOTE_USER are transmitted successfully to the backend J2ee
application as header parameters, if we enable "ShibUseHeaders On" in the above
configuration. In short, request.getHeader("REMOTE_USER") and
request.getHeader("shibattr-email") and so on, returns the expected values, but
still request.getRemoteUser() returns NULL.
The issue at the moment is - NONE of the values are coming to the backend
application if we remove "ShibUseHeaders On". In short, all the above mentioned
Servlet API calls return NULL.
Have we missed any settings? If not, is retrieval of shibboleth attributes
(along with REMOTE_USER) via headers the only option for the backend
application ?
Thanks in advance.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are
not
to copy, disclose, or distribute this e-mail or its contents to any other
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has
taken
every reasonable precaution to minimize this risk, but is not liable for any
damage
you may sustain as a result of any virus in this e-mail. You should carry out
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
