CAS Protocol Milestone

[Cantor, Scott]

We discussed this on the call, but just to get my basic thoughts down on
the list...

Today, we consider any SAML message issued by an SP we don't have metadata
for to be "anonymous, and the SelectRelyingPartyConfiguration step assigns
the Anonymous relying party configuration object. The term is confusing
because what we really mean is "unverified", not anonymous. There aren't
any SAML profiles in general that are really anonymous, and I think if you
assume the CAS client URL is the identity, then clearly CAS isn't either.

By default, the Anonymous selection generally blocks any profiles because
it's empty by default (of course that's a function of the code itself in
the SAML flows, it's not automatic or anything). You can turn on SAML
profiles for that case selectively, and on the call we said that we need
to look over exactly where we expose the relying party identity for policy
purposes even in that case, and where we suppress it.

What I would *like* to do is treat CAS the same way and consider a request
with no underlying registry, whitelist, metadata, call it what you like,
to be unverified, and thus "Anonymous". One definite downside of doing
that is that it means the CAS profile configuration object is only going
to be the one attached to the Anonymous relying party. It didn't sound
like that was necessarily a big problem.

Not allowing attribute filter rules based on an unverified RP was a
problem, but we discussed solving that. And Rod needs to verify this, but
I'm not sure this is even an issue, because I don't think either V2 or V3
now actually disallows AttributeRequester rules in the
Anonymous/unverified case. I don't see what would prevent that; rather, I
think we assumed that people enabling profiles for that case know what
they're getting into. But we need to verify that, and we talked about
adding filtering based on profile too.

The last point I'd make is that there's actually another really simple way
to forcible "verify" CAS requesters such that they become non-anonymous. A
metadata resolver plugin could be written that just gins up fake metadata
objects on demand for any CAS requester, and essentially convinces the
downstream code that a real registry exists. This is of course possible in
SAML too, but we never did it because the use cases never came up. That's
another way of getting policy knobs active without really changing the
model.

So I don't see any impediments here, just fine tuning, a couple of
decisions, and documenting.

-- Scott