NotBefore condition in assertions
Cantor, Scott
cantor.2 at osu.edu
Wed Oct 17 15:33:34 EDT 2012
On 10/17/12 3:16 PM, "Michael A Grady" <mgrady at unicon.net> wrote:
>
> - SPs that interpret it "literally", and without any allowance for clock
>skew, and reject assertions for even just milliseconds of time difference
>(I've encountered this case, and there is clearly evidence in the Shib
>mailing list in the past that others have encountered this
>interoperability problem.)
That *is* a bug, though. I think the solution is to force people to fix
their bugs, not to coddle them by making everybody else work around them.
> - SPs that have decided that NotBefore is a *must* rather than optional,
>and reject assertions that don't contain a NotBefore condition. (I've
>never seen this myself, but since my IdP experience to date is with the
>Shib IdP, and the Shib IdP always sends NotBefore, I guess I wouldn't
>have come across this one. And is, for the same reason, also unlikely to
>have come up on the Shib mailing list.)
I am speculating that's the case because I don't think Andreas would have
proposed it for saml2int otherwise.
>What we don't know -- unless someone on this list does and can confirm
>such -- is if there are SPs out there for which *both* of the above are
>true -- will fail if NotBefore is not present, and interpret NotBefore
>without allowance for skew.
I would think it likely that those mistakes would not be mutually
exclusive.
>So, assuming we discard that approach (any thoughts on the above are most
>welcome),
I definitely would reject that approach.
> the approach that would clearly fit into the SAML standard would be to
>allow for a configurable option to not add a NotBefore condition in the
>assertions (i.e. leave it out of the assertions altogether). And given
>the two different problems above, we'd want that option to be on a
>per-Relying Party basis.
All options tend to be per-RP.
> If we were to create such a configuration attribute, what should it be
>called? Would "omitNotBeforeCondition" with a default value of "false",
>but which could be set to "true", be ok? Or would it be easier to
>understand/"harder to misinterpret" if we did that in a positive tone and
>made it "includeNotBeforeCondition", with a default value of "true"? Or
>something else entirely?
includeConditionsNotBefore would probably be my preference.
>Any thoughts on this? Anyone else who would like to see this option exist
>in the IdP?
I favor having options to control anything in the profile that's optional.
Not because of bugs, but because that's how I approach software. I don't
like hardcoding things.
But as a *deployer*, if you're asking me if I'd use the option, probably
not.
-- Scott
More information about the users
mailing list