SAML1.1 attribute release on Shib 3

[Cantor, Scott]

> 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.

Physically speaking, proxying HTTP to the SOAP port requires that the querying SP be signing its requests or that you turn off security settings in the IdP. I don't know what you're doing exactly, but I can promise you that's the case.

Load balancing of course can involve other approaches that leave end to end TLS/HTTP from SP to IdP, and that would work without the SP signing.

> 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.

Data is passing through the client, and it is not encrypted, not in the client. The client is a cesspool by definition, so if you want to keep data confidential, you don't pass it through there in plaintext. If the data is non-sensitive, then it doesn't much matter.

-- Scott