CAS Protocol Milestone

[Rod Widdowson]

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

No, Null is just another value you can test against.  In fact you *should*
be able to say:

<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
value="" />

To test for exactly that case, but currently the code says "Oh, the
AttributeRequester is null, that’s bad" and makes the policy non relevant.
I think that this is probably a misfeature and we should allow null
AttributeRequester (and AttributeIssuer).  And thus make that above "true"
in that case.  What do others think?

We run into slightly more difficulties if you specify a SAML match functor
(such as saml:AttributeRequesterInEntityGroup), because there ain't no
Metadata.  The code is structured such that if we hit one of them we fail
"no release" - and I tested this (by setting the metadata to null from the
debugger).  I have not (yet) had much getting an anonymous profile request
to work inside the testbed.  

I was going to suggest that we added a couple of other functors, but with
the change I suggest above we have a way of saying "anonymous", and Scott
points out that for all the others (indeed for this as well) we have the
option of PredicateFunctor.

In the shorter term I'd also suggest that we add a new endpoint to the
testbed to exercise the anonymous profile configuration.  Would that be
something to usefully add?  I suspect that it’s a hyperlink looking like one
of the unsolicited end points but with a bogus providerId.

Marvin:
> I'm leaning toward a CAS-specific metadata registry since it
> could be used for other cases like relying party context info on the
> UI or principal attribute selection.

Bearing in mind that I do not have extensive experience in deployment:  I
can see that that would make for a natural deployment for a CAS-only site,
but would having (effectively) two metadata types be an issue for mixed mode
sites?  I'm guessing not since CAS would be on-campus and SAML for
off-campus and never the twain would meet.

To mirror what Scott says, all that the filter code cares about is the API.
And the filtering the use cases (EntityGroups and EntityAttributes) are
pretty SAML specific, and very much non-campus-oriented, so I wouldn't
imagine that even that would matter.