SP behind VPN Gateway: handler locations
Martin Haase
I have a question on how to configure the protocol handlers of an SP
sitting in an intranet for communication with an outside IdP where a VPN
Gateway does URL rewriting.
Normally the HTTP-POST Assertion Consumer would be at:
https://sp1.intra.net/Shibboleth.sso/SAML2/POST
This is o.k. for users in the intranet. Now the VPN gateway does URL
rewriting such that for outside users, the SP's ACS URL would be:
https://my.vpngateway.net/Shibboleth.sso/SAML2/POST/,DanaInfo=sp1.intra.net,SSL
(This Juniper appliance *could* also do a true VPN bridge, but
presumably policy forbids Shib users to have full network access to the
intranet. Hence this URL rewriting interception thing.)
Now I configured this URL in the SP's metadata on the IdP side. The
problem is, the SP sends the above intranet URL as its ACS. Both do not
match, so the IdP complains that there's no peer endpoint available etc.
So how could I achieve that the SP is sending to the IdP the gateway
address as its ACS, whereas actually receiving the assertion on its
usual address?
Here's my set-up:
http://www.daasi.de/shib/shibToJuniperWithApplication.png and it is step
4 I'm concerned about.
Thanx in advance,
Martin
--
-----------------------------------------------------------------------
Dr. Martin Haase
DAASI International GmbH phone: +49 7071 407109-6
Europaplatz 3 Fax : +49 7071 407109-9
D-72072 Tübingen email: Martin...@DAASI.de
Germany Web : http://www.daasi.de
Directory Applications for Advanced Security and Information Management
-----------------------------------------------------------------------
Cantor, Scott
>This is o.k. for users in the intranet. Now the VPN gateway does URL
>rewriting such that for outside users, the SP's ACS URL would be:
>
>
>https://my.vpngateway.net/Shibboleth.sso/SAML2/POST/,DanaInfo=sp1.intra.ne
>t,SSL
>
>problem is, the SP sends the above intranet URL as its ACS. Both do not
>match, so the IdP complains that there's no peer endpoint available etc.
>So how could I achieve that the SP is sending to the IdP the gateway
>address as its ACS, whereas actually receiving the assertion on its
>usual address?
I would start by ignoring the intranet case and seeing if you can get the
outside URLs to work alone. If that ends up working, then the final step
would be having separate Applications in the SP to handle each case.
To make it work, you'd need to use an older-style configuration so that
the ACS endpoints are enumerated in the older way. You would have to add
that suffix to the Locations of those endpoints.
As for the rest, I think you'd have to virtualize the web server's
hostname, but that won't work if you have both sets of traffic hitting one
vhost. So really, I would advise not doing that. If you really can't keep
them to separate vhosts locally, then you can try setting handlerURL to an
absolute URL of https://my.vpngateway.net/Shibboleth.sso
Good luck.
-- Scott
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Peter Schober
> Now I configured this URL in the SP's metadata on the IdP side. The
> problem is, the SP sends the above intranet URL as its ACS. Both do not
> match, so the IdP complains that there's no peer endpoint available etc.
> So how could I achieve that the SP is sending to the IdP the gateway
> address as its ACS, whereas actually receiving the assertion on its
> usual address?
If the ACS URL check at the IdP alone prevents stuff from working you
could apply https://issues.shibboleth.net/jira/browse/SIDP-499 to your
IdP and have the SP sign AuthnRequests.
-peter
Martin Haase
thanks for your answers. It took me some time as we had a longer server
outage. I now brought the IdP past the ACS check, but differently than
Peter suggested. I just added to the SP's metadata at the IdP:
<md:ACS...
Location="https://my.vpngateway.net/Shibboleth.sso/SAML2/POST/,DanaInfo=sp1.intra.net,SSL"
ResponseLocation="https://sp1.intra.net/Shibboleth.sso/SAML2/POST" />
This makes the IdP select and check for the intranet ACS URL but
redirect the message to the gateway's address.
The problem now: in its SAML Response, the IdP sets the destination URL
of the gateway's address as well. The SP does not like that, throwing a
opensaml::BindingException at
(https://sp1.intra.net/Shibboleth.sso/SAML2/POST)
SAML message delivered with POST to incorrect server URL.
I guess the same problem would happen with Peter's solution: the target
in the POST would be the gateway address while the SP receives it at the
intranet address.
Can this check be switched off?
And yes, I am of course aware of
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTroubleshootingCommonErrors#NativeSPTroubleshootingCommonErrors-SAMLmessagedeliveredwithPOSTtoincorrectserverURL
...:
ad 1. I cannot seem to be able to set the SP's server address to the
gateway's address,
ad 2. I cannot seem to be able to influence the gateway's rewrite
rules, and
ad 3. how can I make the IdP redirect to a different URL than the
destination encoded in the SAML response?
As Scott suggested, I used the older config. Tried setting
ResponseLocation for the ACS handler as well, which was ignored. Tried
to set an absolute path there, but this got appended to the handlerURL
like a relative path. Setting an absolute handlerURL of
https://my.vpngateway.net/Shibboleth.sso while having the server listen
on https://sp1.intra.net even made things worse, I seemed to be unable
to access the SP at all.
Do you still have any ideas?
Regards,
Martin
--
Cantor, Scott
>Hi Peter, hi Scott,
>
>thanks for your answers. It took me some time as we had a longer server
>outage. I now brought the IdP past the ACS check, but differently than
>Peter suggested. I just added to the SP's metadata at the IdP:
>
> <md:ACS...
>Location="https://my.vpngateway.net/Shibboleth.sso/SAML2/POST/,DanaInfo=sp
>1.intra.net,SSL"
>ResponseLocation="https://sp1.intra.net/Shibboleth.sso/SAML2/POST" />
>
>This makes the IdP select and check for the intranet ACS URL but
>redirect the message to the gateway's address.
That would be a bug. The check has to be against the location actually
used, and when you set a ResponseLocation, the Location should simply be
ignored. Please file a bug on that.
>Can this check be switched off?
No.
> ad 1. I cannot seem to be able to set the SP's server address to the
>gateway's address,
You need a proper vhost for it.
> ad 3. how can I make the IdP redirect to a different URL than the
>destination encoded in the SAML response?
You can't.
>Tried setting
>ResponseLocation for the ACS handler as well, which was ignored.
I didn't say to do that, I said to add the suffix to the Location. The
rest has to come from your web server. You MUST virtualize it. There is no
other option.
>Do you still have any ideas?
Please re-read my original message and do what I suggested there.
-- Scott
Mike Wiseman
I'm testing IdP v-2.3.3 built-in ECP functionality with an SP. The client access fails with the following IdP error:
...
14:20:50.922 - DEBUG [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:101] - Filtering peer endpoints. Supported peer endpoint bindings: [urn:oasis:names:tc:SAML:2.0:bindings:PAOS]
14:20:50.922 - DEBUG [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:116] - Removing endpoint <SP_endpoint_URL> because its binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST is not supported
14:20:50.922 - DEBUG [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:116] - Removing endpoint <SP_endpoint_URL> because its binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign is not supported
14:20:50.923 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:429] - No return endpoint available for relying party <SP_entityID>
14:20:50.923 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SAML2ECPProfileHandler:237] - Returning SOAP fault
edu.internet2.middleware.shibboleth.common.profile.ProfileException: No peer endpoint available to which to send SAML response
at edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler.populateProfileInformation(AbstractSAMLProfileHandler.java:430) ~[shibboleth-identityprovider-2.3.3.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler.populateRequestContext(AbstractSAMLProfileHandler.java:315) ~[shibboleth-identityprovider-2.3.3.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.populateRequestContext(AbstractSAML2ProfileHandler.java:181) ~[shibboleth-identityprovider-2.3.3.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SAML2ECPProfileHandler.decodeRequest(SAML2ECPProfileHandler.java:305) [shibboleth-identityprovider-2.3.3.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SAML2ECPProfileHandler.processRequest(SAML2ECPProfileHandler.java:183) [shibboleth-identityprovider-2.3.3.jar:na]
...
The two endpoint bindings are listed in the SP metadata. The same functionality works fine with the production IdP v2.2.1 with the ECP plugin and the same SP and metadata. Some equivalent logs from the production IdP:
...
00:00:10.149 - DEBUG [edu.internet2.middleware.shibboleth.idp.ext.ecp.profile.ECPProfileHandler:488] - adding acceptable ep: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
00:00:10.149 - DEBUG [edu.internet2.middleware.shibboleth.idp.ext.ecp.profile.ECPProfileHandler:488] - adding acceptable ep: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign
00:00:10.149 - DEBUG [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:100] - Filtering peer endpoints. Supported peer endpoint bindings: [urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign]
00:00:10.149 - DEBUG [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:64] - Selecting endpoint by ACS index '0' for request '_8045c311-c0df-4fbd-88b1-ba3b507b89df' from entity '<SP_entityID>'
...
Appreciate any help with this.
Mike
Mike Wiseman
Information + Technology Services
University of Toronto
Cantor, Scott
>
>
>The two endpoint bindings are listed in the SP metadata.
What two? The only one ECP supports is PAOS.
> The same functionality works fine with the production IdP v2.2.1 with
>the ECP plugin and the same SP and metadata. Some equivalent logs from
>the production IdP:
I would have to assume, without looking at the metadata so far, that the
extension had a bug.
-- Scott
Tom Scavo
> On 9/1/11 4:26 PM, "Mike Wiseman" <mike.w...@utoronto.ca> wrote:
>>
>>The two endpoint bindings are listed in the SP metadata.
>
> What two? The only one ECP supports is PAOS.
But the SP might authenticate the non-browser client in two different
ways, on two different endpoints. This would be have to be
communicated out-of-band of course.
Tom
Martin Haase
>> ad 1. I cannot seem to be able to set the SP's server address to the
>> gateway's address,
> You need a proper vhost for it.
to understand you right, do you have the following scenario in mind?
1. Access to
https://gateway.net/Shibboleth.sso/Metadata,DanaInfo=sp.intra.net,SSL
from outside intranet
2. Apache on SP is contacted by the gateway under the intranet IP and
hostname
3. Although hostname is sp.intra.net, shibd should think hostname is
gateway.net and generate proper ACS URL
For this to work, I configured an ACS Location of
"/SAML/POST/,DanaInfo=sp.intra.net,SSL" and tried almost every possible
Apache configuration I can think of, but it always boils down to the SP
generating this ACS URL:
https://sp.intra.net/Shibboleth.sso/Metadata,DanaInfo=sp.intra.net,SSL .
And this is what the SP is telling to the IdP in the AuthNRequest as
well, but it is not the URL it can be reached from outside.
So I'm really stuck with point 3. I tried various combinations of
NameVirtualHost, VirtualHost, ServerName, ServerAlias, and some rewrite
rules. If it is doable with Apache config, could you please point me
further into the direction you are proposing? And, did I miss anything
to do to Shibboleth config?
Thanks,
Martin
Cantor, Scott
>>What two? The only one ECP supports is PAOS.
>
>But the SP might authenticate the non-browser client in two different
>ways, on two different endpoints. This would be have to be
>communicated out-of-band of course.
I think you mean IdP, and that's a SOAP binding, not what was asked about
here.
And yes, there's a need to come up with a security policy language for
this now that we can all agree WS-* is pining for the fjords.
-- Scott
Cantor, Scott
>
>1. Access to
>https://gateway.net/Shibboleth.sso/Metadata,DanaInfo=sp.intra.net,SSL
>from outside intranet
>2. Apache on SP is contacted by the gateway under the intranet IP and
>hostname
>3. Although hostname is sp.intra.net, shibd should think hostname is
>gateway.net and generate proper ACS URL
Not shibd, Apache. shibd has nothing to do with it, this is standard web
server setup. Your server MUST be able to inform applications how to
generate self-referential URLs. Redirects MUST be absolute, and
applications hardwriting hostnames into themselves is, well, ridiculous,
so that's why the web server has to be virtualized.
(IIS does NOT support this, as I like to remind people.)
>For this to work, I configured an ACS Location of
>"/SAML/POST/,DanaInfo=sp.intra.net,SSL" and tried almost every possible
>Apache configuration I can think of, but it always boils down to the SP
>generating this ACS URL:
>https://sp.intra.net/Shibboleth.sso/Metadata,DanaInfo=sp.intra.net,SSL .
If that's true, Apache thinks the ServerName is sp.intra.net for requests
to whatever vhost is handling them.
>So I'm really stuck with point 3. I tried various combinations of
>NameVirtualHost, VirtualHost, ServerName, ServerAlias, and some rewrite
>rules.
There is nothing involved but ServerName. The rest involve how the Apache
server maps client-supplied inputs to selecting the vhost to actually use.
Those might be causing the wrong vhost to be handling requests, but they
won't change how the server reports itself to applications.
Cantor, Scott
>>So I'm really stuck with point 3. I tried various combinations of
>>NameVirtualHost, VirtualHost, ServerName, ServerAlias, and some rewrite
>>rules.
>
>There is nothing involved but ServerName. The rest involve how the Apache
>server maps client-supplied inputs to selecting the vhost to actually use.
>Those might be causing the wrong vhost to be handling requests, but they
>won't change how the server reports itself to applications.
Correction...they might affect what gets reported, if UseCanonicalName is
Off. If it's On, ServerName rules.
Martin Haase
Am 02.09.2011 22:30, schrieb Cantor, Scott:
> Correction...they might affect what gets reported, if UseCanonicalName is
> Off. If it's On, ServerName rules.
Great! That did the trick, thank you. It is now closer, but, alas!, not
there yet. Now SP and IdP agree that the ACS location of
https://gateway/Shibboleth.sso/SAML/POST,DanaInfo=sp1.intra.net,SSL
is to be used. The IdP also redirects there. Once it passes through the
gateway, it proxies the URL and the gateway sends a request to
https://sp1.intra.net/Shibboleth.sso/SAML/POST.
What happens: the SP receives it, but does not know anymore how to
handle this location, claiming it is unconfigured, which is true after
all (i.e. that path, the host does not seem to matter).
Giving the SP a second ACS URL of "/SAML/POST" with the same binding
leads to a mismatch ("Post targeted at <gateway location> but delivered
to <the usual one>"). Could this check be circumvented?
On the other hand, I tried a rewrite rule rewriting /Shibboleth.sso/(.*)
into /Shibboleth.sso/$1,DanaInfo=sp1.intra.net,SSL. This seemed to have
no effect, both in server and in vhost context. Can you confirm that
mod_shib runs before any rewriting is done?
Any more ideas?
Besides, I filed the IdP bug about the incorrect treatment of
(Response)Locations.
Regards,
Cantor, Scott
>
>Giving the SP a second ACS URL of "/SAML/POST" with the same binding
>leads to a mismatch ("Post targeted at <gateway location> but delivered
>to <the usual one>"). Could this check be circumvented?
No. I thought you meant that the URL the SP sees had the suffix on it. If
the URLs don't match, it won't work.
>On the other hand, I tried a rewrite rule rewriting /Shibboleth.sso/(.*)
>into /Shibboleth.sso/$1,DanaInfo=sp1.intra.net,SSL. This seemed to have
>no effect, both in server and in vhost context. Can you confirm that
>mod_shib runs before any rewriting is done?
I don't know. Apparently sometimes it does. Apache's module ordering
control is fairly unpredictable.
>Any more ideas?
Not really. I believe there are VPNs with SAML support, and this kind of
thing is probably why.
Martin Haase
--