Problems with shared associations near expiration
andrewarnott at gmail.com
Sun May 8 22:09:30 UTC 2011
I'm not on any "spec body", but I would suggest a combination of #2 and #5,
Either party (RP or OP) can fix the misbehavior by avoiding the use of
near-expiry associations. It is already advisable from a security
standpoint to consider clock skew and a maximum timeframe allowable for a
user to complete an authentication (for nonce checking). Given then that
OPs and RPs already (should) have this time limit built in, it is
straightforward to apply this time limit to the remaining lifetime of an
association and drop associations not guaranteed to last long enough to
complete the authentication. For instance, if an association only has 30
minutes left and you allow for 10 minutes to complete authentication
(including allowing for clock skew where applicable), the association has
only 20 minutes of meaningful life left, after which it should be discarded.
If the RP implements this, it will drop the near-expiry association and
request a new one from the OP 10 minutes before the last association has
technically expired. Problem solved.
If the OP implements this, it will see an association handle that it knows
is nearly expired, realize the RP will (or should) reject the assertion
after the OP makes it, and revert to dumb mode. The OP's time window for
considering an association useless may be smaller than an RPs, since by the
time the OP is deciding whether to sign the assertion the authentication is
nearly complete and the RP should be only moments away from validating the
signature. So if the OP reverts to a private association (possibly sending
invalidate_handle as well) it will keep the user experience correct, with
the only possible side-effect being that the RP had to follow stateless-mode
behavior for one or a few authentications.
To summarize, the user experience can be made reliable, without sacrificing
security, with work done on either the RP or the OP side. And a decent
OpenID library should (IMO) absolutely either have this behavior built-in,
or allow through normal configuration or extensibility points for the host
site to create this behavior.
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Fri, May 6, 2011 at 12:59 PM, Drew Clippard <dclippard at gmail.com> wrote:
> I'd be interested in hearing clarification on this issue, too.
> In my experience, I've seen issues with both Java and Ruby relying
> party libraries and stateful associations. When dealing with a large
> volume of log-ins near the boundary of association expiration, some
> users end up getting a bad experience (the equivalent of a "log-in
> failure" in their eyes) through no fault of theirs.
> It seems the that the only reasonable fix is for relying party
> libraries to somehow compensate for this. Is that right?
> I'm guessing that since no such fix has been implemented in these
> libraries, that one of (or possibly many) of these less-desirable
> outcomes tend to be taking place out in the wild:
> 1) OPs cranking up their lifespan of associations. This workaround
> sacrifices security and doesn't really address the problem. It just
> makes the negative side effects happen less frequently.
> 2) OPs implementing potentially surprising behavior (similar to the
> DotNetOpenAuth OP described above)--where the OP is ignoring
> association handles that are close to expiring, yet not returning an
> 3) RPs opting to use stateless associations exclusively (despite the
> OpenID spec's encouragement otherwise).
> 4) RPs having to forgo common libraries and implement their own
> association management utilities that continue to accept
> "late-arriving" assertions during a grace-period window.
> 5) RPs having to forgo common libraries and implement their own
> association management utilities that establish new associations well
> in advance of the expiry of existing, still-valid associations.
> So, I second Mr. Randall's request for clarification on the spec?
> Which party (RP or OP) should be addressing this issue and how?
> Of the 5 options described above, 1 and 3 seem clearly undesirable,
> and 2 would only feel comfortable with some acknowledgement from the
> spec body. 4 and/or 5 seem reasonable. Yet, some guidance from the
> spec authors would undoubtedly add some expediency to such
> enhancements being implemented in these various projects.
> Thanks for any guidance you can provide.
> specs mailing list
> specs at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the specs