Implications of forceAuthn/AuthnInstant

[Cantor, Scott]

On 10/1/13 8:43 PM, "Eric Goodman" <Eric.Goodman at ucop.edu> wrote:
>
> 
>The apps I¹m talking to effectively want a ³sudo² function for SSO, where
>for some ³elevated privilege² operations (or SPs), they can force a
>reauthentication, even though the authentication method isn¹t changing.

Yes, that's fairly typical of the use case.

> 
>The more I look into this, the more it seems like there¹s no real way to
>enforce this in an open federation.

If you're asking if the ability to use SSO features that go beyond the
most vanilla is inversely proportional to the number of IdPs you have to
support, that's certainly true.

Most of the advanced ones are designed around enterprise use cases.

> We can leverage the forceAuthn/AuthnInstant/maxTimeSinceAuthn features
>to make the SP enforce such a policy in a literal manner, but in many
>cases (e.g., CAS-ified or webauth-ified Shib) it appears that even if the
>Shib IdP itself honors the forceAuthhn and re-authenticates the user (by
>no means certain), there¹s no way to ensure that there was an actual user
>interaction in that re-auth.

That's a slightly different issue. There you have a broken deployment.
Your IdP MUST NOT be configured to support ForceAuthn if you're handing
off control to software that doesn't support that feature. That's why the
LoginHandler schema allows handlers to be configured with that
information. The IdP checks for that support before it dispatches control
to a LoginHandler.

> I.e., if Shib relies on CAS for authentication, CAS can provide a
>³fresh² authentication to Shib without the user seeing any actual prompt
>to re-enter credentials.

Yes, that means your login handler should not indicate support for
ForceAuthn.

> 
>In effect, ³all or nothing SSO² ­ which we¹re pretty much all using with
>federated authentication and I *think* many are when using CAS and
>similar tools ­ means that the authentication control point (after
>initial login) is at the
> device level, not at the application level (for the duration of the SSO
>session).

That depends on the IdP and on the login handler.

> 
> 
>Questions
> 
>1) Is my assessment of the inability to enforce this across a federation
>generally correct?

If you mean "will most or all IdPs support ForceAuthn?", the answer is no.
If there are IdPs doing what you suggest above, though, that's not lack of
support, that's disregard for the rules of the road. An SP must be able to
rely on the IdP doing what it asks or returning an error.

In particular, the IdP had certainly better not reset the AuthnInstant in
such a case. That would be a pretty blatant error.

>In short, I¹m saying that without having policy/implementation control
>over all of the IdP operators you interact with, the SP has no way to
>enforce any form of authentication outside of ³all or nothing SSO² (at
>least with the same authentication
> context). It can do things that try to encourage it, but it¹s not
>actually enforceable.

It's not enforceable if the IdP lies to you, certainly. maxTimeSinceAuthn
enforces your policy just fine as long as the value is accurate, even if
the IdP is broken and fulfills the request without following the spec. So
you'd have two errors there combined.

> 
> 
>2) Have campuses (well, probably more ³university systems²) developed any
>standard policy and technical frameworks for IdP operation that would
>allow for such enforcement? Do campuses just assume the ³all or nothing
>SSO² model?

My IdP follows the spec, so it doesn't claim to support things it doesn't.
But I happen to support ForceAuthn, FWIW.

My issue with ForceAuthn BTW is one you haven't noted. The fact is that
the stronger the authentication you use, the weaker the presence proof.
Consider SPNEGO/Kerberos. Totally seamless and absolutely no proof the
user is still there using the browser, and ForceAuthn does nothing but
refresh the ticket exchange off a TGT that's in the cache. Same for a PKI
token with the PIN entered.

-- Scott