Checking contextual integrity

Cantor, Scott cantor.2 at osu.edu
Fri May 24 10:14:39 EDT 2013


> There's the rub.  I think that it is reasonable to expect the Principal,
> RequesterID and IssuerID to be present, and it is realistic to check for
> that.  Equally, in SAML flows I think that it is reasonable to have the
> Requester metadata available (so most of the metadata based filters will
> work).

It's not. Consider anonymous requesters (and yes, filtering there doesn't work well, but it still has to do something sensible).

> I know you dislike the term so I'll not say "trust but check".  I think that
> safe has to be to issue and warning and return false.  Then the only case
> impacted wrongly is the less common <DenyAttribute/> case.  Further this
> sort of failure will not be transitory, it is a config issue.

I don't think it's exclusively a configuraton error, unless we posit that to get to a Deny Rule you have to pass a PolicyRequirement check, and that's where you would stop any possible ambiguities.

But I don't think we can assume "safe" is false (except in the policy requirement check). Which is I think the problem you were pointing out. What I would assume, then, is that a predicate object would be instantiated by a rule with a property set for what value "safe" is. Then the predicate doesn't have to know ahead of time. Does that work?

-- Scott





More information about the dev mailing list