CAS Protocol Milestone

Cantor, Scott cantor.2 at osu.edu
Mon Aug 18 11:02:27 EDT 2014


On 8/18/14, 10:53 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>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="" />

I don't think so (I think XML actually doesn't allow that?), but
regardless that's not what we mean here. That would be a truly anonymous
request, but neither SAML nor CAS requests are anonymous.

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

I don't think you can, at least without changing syntax, and no, I don't
really see that we have this use case. This isn't the case we're
discussing.

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

That's by design. Nobody is expecting that a request without metadata
would work with a metadata-driven policy rule.

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

Yeah, that's easy enough.

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

That's going to be a matter of choice, but anybody that wants to invent
new metadata syntaxes is free to do so now. They'll never be blessed as
recommended by the project though. SAML metadata can handle CAS just fine.
You have to define a protocol support constant and a binding constant,
both of which are likely one and the same (and equal to the profile
constant used in the code/config).

-- Scott



More information about the dev mailing list