Implications of forceAuthn/AuthnInstant

[Eric Goodman]

Hi all,

This is Shibboleth-related, but really more a "SAML and campus policy" set of questions. Please feel free to redirect me if there is a better forum for the discussion.

Background

We've been looking at using forceAuthn/AuthnInstant/maxTimeSinceAuthn for some apps where the app owners want to leverage federated authentication, but really don't want "all or nothing SSO". By "all or nothing SSO", I mean a setup where users are either logged into SSO, with access to all SSO-protected systems (SSO is "on") or are "logged out" of SSO with access to no SSO systems until reauthenticating.

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.

The more I look into this, the more it seems like there's no real way to enforce this in an open federation. 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. 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.

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


Questions

1) Is my assessment of the inability to enforce this across a federation generally correct? Are there technical options/restrictions I'm overlooking?

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.


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?


3) If campuses do use the "all or nothing SSO" model, has there been formal security review of the new practice - i.e., CISO or similar review? Do campuses make concerted efforts to inform end users of the security implications? (In my experience, most frequently it's application developers that have the impacts explained to them, and mostly so they'll stop complaining about the lack of a logout link that works the way they want.)


I would appreciate your thoughts on any of the above. I'm particularly interested in any examples of campuses or systems that have deliberately crafted policy and user training in a change-managed way, rather than having the issues form in a "grass roots" sort of way as a side effect of integrating systems via SSO/Federation.


Thank you for any input,

--- Eric





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20131002/f3d6262a/attachment.html