IIS 7.5 Server behind an F5 Reverse Proxy

Meiselman, Ellen emeiselm at med.umich.edu
Wed Aug 20 10:37:40 EDT 2014


Thank you Chris - this was extremely helpful. You stopped me from going down a dead end. I checked the Native error logs and found it was giving this error:

  ERROR Shibboleth.ISAPI [3820] isapi_shib: Unable to locate metadata for identity provider

Which to me means a bad path tot he IdP metadata file, most likely. I then revisited the shibboleth.xml settings file and corrected the relative paths to /Metadata, /Session, etc. since they now have the reverse proxy-necessitated directory /content/in the path.  I added handlerURL=/content/Shibboleth.sso" to the Sessions element.

  <Sessions lifetime="28800" timeout="3600" relayState="ss:mem" handlerURL="/content/Shibboleth.sso"
                  checkAddress="false" handlerSSL="true" cookieProps="https">

Now if I browse to
https://proxyserver.com/content/Shibboleth.sso/Metadata
I get this message from the IdP:

Error:Unable to complete request at this time. (Request was from an untrusted provider-31DE48E3C3946D8E)

Which is a whole lot farther along than before.

Now here is where I am confused still. The metadata.xml file in /etc/ was given me by my IdP, and was at least apparently working before I changed hostnames. The only locations it contains all refer to the IdP. So that is the Identity Provider metadata, correct?

I tried the endpoint .../Shibboleth.sso/Metadata on another content server I have that is functional. That endpoint gives me what looks like it must be SP metadata.  Is that xml file entirely generated by Shibboleth according to some template? Or have I just not found the file yet? What controls what goes into that file?



Thank you very much for your help!

Ellen
______________________________
Ellen Meiselman
University of Michigan Health System
MLearning
NCRC
2800 Plymouth Rd.
Building 200, Rm 207
Ann Arbor, MI 48109-2800
E-Mail:  emeiselm at umich.edu<mailto:emeiselm at umich.edu>
Phone (734) 936-2334

On Aug 19, 2014, at 12:04 PM, Christopher Bongaarts <cab at umn.edu<mailto:cab at umn.edu>> wrote:

On 8/19/2014 10:38 AM, Meiselman, Ellen wrote:
I  installed shibboleth on an IIS server  - call it contentserver.com<http://contentserver.com>. Everything was working.

Then we put that server behind an F5 reverse proxy  - let's call its hostname "proxyserver.com"

So now, pointing the browser to https://proxyserver.com will display content that is actually on https://contentserver.com

How do I set up the SSL certs so shibboleth will work for requests that come in to https://proxyserver.com? I have only very basic knowledge of how to install and bind certs.

Right now I can't get Shibboleth working again. The plugin is up and running but I can't get the appropriate metadata from the IDP because I can't give them the correct certificate - at least I don't *think* I can. I don't know how to install a certificate that is for another hostname.


Keep in mind that there are usually two sets of certificates in play here - an SSL certificate that is used to secure your HTTPS traffic, and a SAML encryption certificate that is used by Shibboleth.

Your SSL certificate is configured in the web server (IIS GUI in your case).  This is the one that you typically buy from a public certificate authority.

The Shib certificate (and corresponding private key)  is normally generated at installation time and lives in the Shib configuration directory alongside shibboleth2.xml.  Default name "shib-sp.pem" I think.  The certificate details are not used at all by the Shib software - the server name, expiration, CA signatures etc. are all irrelevant.  It is just used as a convenient way to carry a public key.  The Shib certificate is the one that is included in your SP's metadata file (that you give to your IdP).

Also in the SP metadata file are several SAML endpoints (the XML elements that contain a Location attribute).  They tell the IdP how to direct SAML messages to your SP.  If you've changed the publicly-facing name of the server, you'll also need to update these endpoints so they contain the correct URLs (as viewed by the browser).  Since you're on IIS, you'll also need to verify that your Site directives in your shibboleth2.xml file are correct.

If you use the metadata generator endpoint (/Shibboleth.sso/Metadata), it will include the currently configured certificate and whatever virtual hostname was used to access it in the endpoints.

In all likelihood, you've left your Shib certificates alone, so in theory the only thing you should need to do (on the Shib side) is change the Locations of the endpoints in your metadata, and ask the     IdP to use the updated metadata.
--
%%  Christopher A. Bongaarts   %%
cab at umn.edu<mailto:cab at umn.edu>
          %%
%%  OIT - Identity Management  %%
http://umn.edu/~cab
  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140820/945282ad/attachment.html 


More information about the users mailing list