On 30-Jun-09, at 9:23 PM, Allen Tom wrote:
Many websites require users who are already authenticated to re-
verify their password before entering a sensitive area.
For instance, retailers like Amazon allow users to browse their
website in a recognized state, but will verify the user's password
in order to place an order. Similarly, Facebook requires logged in
users to re-verify their password in order to manage their credit
cards, and Yahoo and Google have similar password verification
requirements in order to enter sensitive flows.
The PAPE Extension seems to be the right way to implement this
functionality in OpenID, and I believe that the authors of the PAPE
spec intended RPs to be able to specify openid.pape.max_auth_age=0
in the request to ask the OP to authenticate the user without
relying on browser cookies. In the case where the user is already
authenticated at the OP (using cookies), the expectation is that the
OP re-authenticates the user before returning a positive assertion
to the RP. In the most common case, where the user authenticates
with a password, the OP is expected to verify the user's password
before returning the assertion to the RP.
Although this sounds fairly straightforward, there are some non-
obvious edge cases that should probably be clarified.
For instance, what if the RP specified max_auth_age=<1 minute>?
Sometimes users take a few minutes to complete the OpenID sign in
flow (they might get distracted), and although the user may have
entered their password immediately after being redirected to the OP,
the user may have taken more than a minute to navigate through the
OP's approval screen, before clicking on the button to return back
to the RP.
Another case is where the RP specified max_auth_age=999999999999.
The PAPE spec requires the OP to respond back with the the time the
user last authenticated, if the max_auth_age is greater than the
duration of the user's current session with the OP. This effectively
gives the RP a way to find out when the user last signed in, which
potentially violates the user's privacy. Many users expect to be
able to sign into their OP silently, and to be able to use services
at their OP without anyone besides their OP knowing that they were
online. Obviously, using OpenID to signin to an RP exposes to the
RP that the user is online at the moment of authentication, however
it's probably a very bad idea for the OP to return when the user
signed into the OP if the sign-in event was more than (X hours?) in
the past.
In order to provide a standard "force authentication" interface, I
propose that either we define a new PAPE policy, or we clearly
define max_auth_age=0 as a special value.
Rather then return the time the user last authenticated, the OP return
the max_auth_age value the RP sent. This lets the RP know the OP
honored the RP's max)_auth_age request.
As for the max_auth_age=1 case, if the OP has seen the user in 1
minute or less when they see the user returning, then the OP does not
need to re-authenticate the user, even if it takes a few minutes for
the OP and user to complete returning the result back to the RP.
The "force authentication" policy must require OPs to re-
authenticate the user after the user is redirected to the OP and
before returning the assertion to the RP. In the case where the user
is authenticated with a password, the OP is required to re-verify
the user's password. If the OP displays additional screens to the
user after verifying the user's password, the OP must ensure that
the user's IP address did not change after the password was verified
and the assertion returned. OPs should be able to support this
policy without also supporting other non-zero values for max_auth_age.
What are you looking for in this use case where the IP address changes?
-- Dick
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
