[OpenID] Durability of authorized sessions

Peter Williams pwilliams at rapattoni.com
Wed Nov 28 17:31:54 UTC 2007


 
lets go through the mashup use cases so critical to a web2.0-centric SSO protocol:-
 
1. RP1 asks OP for a cliamset, citing some minimum PAPE requirements. OP delivers the cliams, having done an interactive user auth task at or beyond the minimum requirement set by the RP via the PAPE signal. For example, the OP interactively challenges the user to type in a one-time password token and pin to obtain 2-factor assurance.
 
2. RP2 asks same OP for a cliamset, citing lower or no PAPE requirements. OP delivers the claims, without having show the user another tokecode+pin page set experience.
 
The RP2 request comes infact 100ms after the OP replied to RP1; as the two RP websites happen to be involved in a mashup on the landing page of some portal website invoked by the user. In the first RP1->OP flow, the OP took the user through a full 2 factor strong auth logon experience, issuing a local OP-session cookie. In the second case, the OP relied on this local-cookie as evidence of (recent) strong user auth, and immediately and duly replied with the second cliamset.
 
The above is how I have assumed OpenID is supposed to work (which is essentially the same as SAML-based WebSSO).
 
------------------
 
In SAML2, an RP such as RP2 can provide a second (PAPE-like) field requiring that the OP should NOT involve the user interactively - in formulating its claimset. That is... it is really saying: use an OP-local-cookie issued earlier, where reasonable. If its not reasonable to still rely on such a cookie, the OP should respond with - unable to satisfy RP requirements: no claims available. The RP can then invoke the flow again, lessening the "no-interruption" restriction and thereby allowing the OP to present an interactive logon experience...featuring password, or bio, or 2-factor or whatever X grade of user auth satisfes the RP2's PAPE requirement. If RP1 comes back again to the OP, with a PAPE requirement that is higher than X, then the OP MUST interupt the pageflow and satisfy the requirement at the higher standard (assuming it supports it).
 
-----------
In US Realty, we are at the point where folk are wanting this kind of regime. If a user logs on to the OP NOT using 2-factor auth (because the user left their logon token at home, today) and is allowed to fall back to password logon for a day with more limited access rights... one RP website may accept such watered-down auth claims - suiting its risk management posture. The second RP however may reject such lowering of the user auth assurance level - and force the user through the OP's full 2-factor pageset process. That is... its saying: go home Realtor...and get your token (mandatory for my site), else you cannot continue...(at least here).
 
Obviously, the risk management postures of multiple, autonomous RPs using a common OP will never be entirely harmonized. Some will be more fussy than others. Some sites like banks have minimum rules, by regulation. This all then brings us back to the issue of hub-based federation policies and standards _imposed_ on the spokes, to create a uniform assurance and id mgt environment that works (at least) for the poor end-user.

________________________________

From: general-bounces at openid.net on behalf of Tony Locke
Sent: Tue 11/27/2007 11:48 PM
To: general at openid.net
Subject: [OpenID] Durability of authorized sessions



Allen Tom wrote:

> [...] authorizing financial transactions generally requires that
> the credentials be relatively short lived (like an hour) and be tied to
> a specific IP address. In contrast, consumer oriented websites generally
> tend to issue long lived credentials that are not bound to an IP address
> (as consumers tend to roam and get re-IPed fairly often).  A
> consumer-focused OpenID Provider may issue long lived credentials that
> persist across browser sessions and IP address changes so that their
> users don't need to type their password very often.

As I understand it, with OpenId it's the RP and not the Provider that
decides how long the original authentication lasts, and it's also the
RP that decides what constitutes a session (ie, whether a session is
broken by a change of IP address). I guess most RPs define a session
with a cookie that persists until you close the browser. More
stringent RPs could demand re-authentication every 30 minutes, say,
and on each change of IP, and perhaps if 10 minutes goes by without
any interaction.

Regards,

Tony.
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general





More information about the general mailing list