Shibboleth SP - What triggers redirection through Embedded Discovery Service?

Ken Weiss ken.weiss at
Fri May 9 17:46:01 EDT 2014

I apologize in advance for what will, I'm sure, be a someone rambling post... I'm at a level of ignorance on this issue that makes it hard for me to even describe it clearly, so at this point I'm just hoping for some pointers as to where I should start looking to better understand what's going on.

I have several virtual hosts running in the same instance of Apache, using the same instance of shibd and the same shibboleth2.xml file. However, the vhosts are in different domains. In this example I have two web sites secured by Shibboleth, and Each vhost has its own set of Shibboleth configuration statements. The Shibboleth config is very simple:

# Start of Shibboleth config

# Protect everything with Shibboleth authentication
  <Location />
     AuthType shibboleth
     ShibRequestSetting requireSession 1
     require shibboleth
     ShibUseHeaders On
     Allow from all

# Exclude /xtf/* from Shibboleth authentication to allow free access to the search application
  <Location /xtf>
     Satisfy any

  ######### End of Shibboleth config

The basic use case of an individual from a given domain logging in to the server for their domain works just fine. If I (a person) access I am redirected to my local EDS. I select the UCOP IDP from the list, provide my credentials to the UCOP IDP, and get redirected to the page on the site that I originally requested. The same use case works for a Berkeley person accessing the site.

The glitch arises when a person attempts to go across domains. We want people to be able to access certain parts of other domain's sites freely (the search application), but when accessing the Shibboleth-protected areas, we want to force them back to their own domain. To accomplish this I added configuration to the Apache virtual hosts like this:

  RewriteCond %{LA-U:ENV:Shib-Identity-Provider} ucop
  RewriteRule ^/(.*)${REQUEST_URI} [R,QSA,L]

That configuration is part of the setup for It says that if a user comes into the Berkeley site with credentials that were validated by the UCOP IDP, their request is rewritten to send them to Converse configuration for sends Berkeley users back to their home site. This works nicely, except for one odd behavior.

When the user is redirected from the Berkeley site to the UCOP site, they are sent through the EDS again first. They do not need to enter any credentials again. They simply need to select their IDP, and then they are immediately sent to the destination, directly from the EDS page, without going through the IDP. At least, that's how it looks from the browser. I guess it's possible that they are, under the covers, being sent to the IDP and then immediately sent to the UCOP site.

So what I see in this flawed use case is this:

1) User from UCOP goes to

2) Shibd intercepts the request and diverts the user to the EDS page

3) User selects the UCOP IDP and enters their credentials

4) User is redirected to, per their request in Step 1

5) Before the user sees anything in their browser, the rewrite rule in the configuration for notices that their authentication came from UCOP and rewrites their request to

6) Shibd intercepts the request for, and even though the user has a valid session, sends them back to the EDS page

7) User selects the UCOP IDP and is immediately delivered to, without re-entering their credentials or even seeing the UCOP IDP.

Steps 6 and 7 are the problem. I don't understand why my SP is sending the user back to EDS when they already have a valid Shibboleth session. Can anyone give me some clues as to how to even begin to debug and resolve this? Or is this an expected behavior - just part of the way we expect Shibboleth to behave when crossing from one DNS domain to another?


Ken Weiss                                 ken.weiss at<mailto:ken.weiss at>
UC Office of the President              510-587-6311 (office)
California Digital Library              916-905-6933 (mobile)
UC Curation Center
415 20th Street, 4th Floor
Oakland, CA 94612

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the users mailing list