CAS / attribute filtering

[Cantor, Scott]

On 6/9/17, 8:26 PM, "users on behalf of Rory Larson" <users-bounces at shibboleth.net on behalf of rlarson1 at unl.edu> wrote:

> So if we use attribute filtering with CAS, we have some risk of handing out a restricted attribute to the wrong party, because we
> only know the machine's location, but the communication among principal, IdP and SP is not encrypted?

There's a risk, whether you think the risk matters is personal. TLS encrypts, but there's no authentication of the CAS client beyond the location the ticket is sent.

>  If the relying party for the attribute release is specified in the Shibboleth/CAS IdP configuration, would that mean that another
> machine was spoofing its location with a man-in-the-middle attack or something?

Essentially. DNS poisoning, users ignoring cert warnings, that kind of thing.

Or, consider a compromised account. I can use /etc/hosts to fool your IdP into issuing a ticket to any site I control and then retrieve the attributes with it, and then see the data for the account.

With encryption in SAML or authentication of the query/artifact fetch via key, I can't do that. That's the main issue.

Most people don't care because it's piecemeal, one account at a time, and they just don't see it as a big deal. I don't care that people disagree, I only care that it's noted as a difference.

> Anyway, thanks for the response.  It sounds like it might not be ideal to release restricted attributes in a CAS setting, even if it is
> possible to do.

I'm just saying the meaning is different even though the syntax of the rule looks the same.

The URLs in that rule in SAML are very different than with CAS.

-- Scott