SAML1.1 attribute release on Shib 3

[Morris, Andi]

We are definitely proxying 8443 at the moment with Shib 2, and the config of that server is pretty much out of the box (I'm not confident enough with Shibboleth to do much else!). Therefore it must be the reverse proxy acting in a way that pleases both the SP and the IdP I guess. I'll have to see if my other reverse proxy can behave in the same way somehow, or give the server a routable IP address.

" Then I think you may be in for a surprise when you figure out what you're doing already."

Would you mind explaining the difference in the risk with passing the targetedID attribute via attribute push over encrypted SSL/443 to a known, named SP, compared with using the backchannel? I don't understand the difference between the two.

Cheers,
Andi

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: 15 February 2017 19:27
To: Shib Users <users at shibboleth.net>
Subject: Re: SAML1.1 attribute release on Shib 3

On 2/15/17, 2:10 PM, "users on behalf of Morris, Andi" <users-bounces at shibboleth.net on behalf of amorris at cardiffmet.ac.uk> wrote:

> Strange, we have saml1.1 working with a reverse proxy currently, and it had been working well for years.

Then I would suggest you're missing a piece of information somewhere. There is something about what you're doing now you're not taking into account, but I don't know what it might be. The most likely is just that you're not proxying port 8443, only 443.

> That's on shib 2.

Both versions are going to require authentication of the query unless you have deliberately disabled the checking, and only one way of doing that works with proxies. And that way doesn't work out of the box with Shibboleth SPs operating in with the defaults, it doesn't sign messages sent over SOAP.

> Short of putting the IdP in the DMZ that's the only way I can see to
> do it, which could be an option I guess. It's far from ideal however.

Then I think you may be in for a surprise when you figure out what you're doing already.

My servers are load balanced at layer 4 with end to end TLS, though that isn't because of the back channel, it's because proxying makes it extremely difficult to get a trustworthy client address and operating an IdP without trustworthy client addresses is itself a much bigger security risk to my users than not proxying is. The concept of a DMZ means nothing to me, I don't trust any network.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
________________________________

[Cardiff Metropolitan University - Queens Anniversary Prizes 2015]<http://www.cardiffmet.ac.uk/news/Pages/Cardiff-Met-research-recognised-in-Queens-Anniversary-Prizes-for-Higher-and-Further-Education.aspx>