[OpenID] canonical Identifier URL, without using delegated authentication
Peter Williams
pwilliams at rapattoni.com
Sun Jul 8 22:03:03 UTC 2007
Agreed.
6 needs to convey back and forth a state vector, which upon return
reconnects the browser to the OpenID Provider state machine, which is in
a wait state. The "indication" of the state vector + the result of the
user authentication will allow it to resume its processing.
We already demonstrated this basic process, when we took the JanRain
Provider and made the browser follow redirects back and forth to/from
the login site at a third party site ... before the JanRain provider
continued upon return from user auth with the OpenID state machine.
From: Recordon, David [mailto:drecordon at verisign.com]
Sent: Sunday, July 08, 2007 2:56 PM
To: Peter Williams; general at openid.net
Subject: RE: [OpenID] canonical Identifier URL,without using delegated
authentication
For 6 and 7, as long as the Provider maintains the OpenID Authentication
request through the login redirects then it shouldn't be a problem. It
just needs to maintain the state so once the user logs in they can
proceed, allow the OpenID request, and then have the Provider redirect
them back to the RP.
--David
From: Peter Williams [mailto:pwilliams at rapattoni.com]
Sent: Sunday, July 08, 2007 2:53 PM
To: Recordon, David; general at openid.net
Subject: RE: [OpenID] canonical Identifier URL,without using delegated
authentication
The only amendment Id make concerns 6 and 7.
Hey Peter,
I think I'm following you...
1) The End User provides
https://login.rapmlsstg.com/IdpSsoHandler2.aspx?Target=https%3a%2f%2fsso
.rapmlsstg.com%3a12030%2fidp%2fstartSSO.ping%3fPartnerSpId%3drapattoni:s
tg:customer%26IdpAdapterId=STGIdp%26TargetResource%3dhttps%3a%2f%2petera
ccount.rapdata.com/&Contract=2 to the RP.
2) The RP fetches the Claimed Identifier which has a series of 302
Redirects (to a logged out user-agent...the RP) which end at
https://peteraccount.rapdata.com/.
3) https://peteraccount.rapdata.com/ is now the canonicalized Claimed
Identifier.
4) The RP performs discovery on the Claimed Identifier resulting in an
HTML-Based Discovery openid.server tag with the value of
https://login.rapmlsstg.com/sp/SsoHandler.aspx.
5) The RP redirects the user to
https://login.rapmlsstg.com/sp/SsoHandler.aspx with the appropriate
OpenID Authentication request.
6) The user authenticates however they need to, or is already
authenticated.
7) The user allows the transaction at their Provider which responds to
the RP.
--David
6) the sp/SsoHandler.aspx redirects the browser with 302 responses one
or more times, to some remote login-site where the user authenticates
however they need to, or is already authenticated.
7) after user authentication, the login site redirects the browser one
or more times back to sp/SsoHandler.aspx, whereupon the user allows the
transaction at their Provider which responds to the RP.
If we can agree that this is generally consistent with the intent and
model of OpenID, I'll go and build it. It would be merely an extension
of the OpenID experiment we already performed, with folks at
www.scardsoft.com.
FYI:
The redirects on the front and back ends provide me with great added
value. They will allow me resolve such as XRIs without using a proxy
architecture. An XRI form of Claimed Identity
(https://mls.com/=Peter.Williams) can now be resolved as a side effect
of OP provider discovery. Similarly, a protocol of "trusted redirects"
can secure the discovery process itself, automatically deliver
name-federation-based name resolution, and optionally automatically use
pseudonyms to enforce privacy firewalls during a discovery run that the
discovery subsystem recognizes as crossing security domain boundaries.
-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Peter Williams
Sent: Friday, July 06, 2007 11:39 PM
To: general at openid.net
Subject: [OpenID] canonical Identifier URL,without using delegated
authentication
Let's test an edge case of the following "Note" in the specification:
"The End User is NOT REQUIRED to prefix their Identifier
URL with "http://" or postfix it with a trailing slash. Consumers MUST
canonicalize the Identifier URL, following redirects, and note the final
URL. The final, canonicalized URL is the End User's Identifier. "
[http://openid.net/specs/openid-authentication-1_1.html]
This seems to imply that if the Consumer gets a series of 302 HTTP
redirects it must follow the location headers in the response(s) till it
receives a 200 response which also delivers an HTML resource (with at
least markup for the openid.server link value).
Ok. Lets now pick a silly (but legal) edge case of this rule. Lets make
the "Identifier URL" typed into the Login field [s3.2]:
https://login.rapmlsstg.com/IdpSsoHandler2.aspx?Target=https%3a%2f%2fsso
.rapmlsstg.com%3a12030%2fidp%2fstartSSO.ping%3fPartnerSpId%3drapattoni:s
tg:customer%26IdpAdapterId=STGIdp%26TargetResource%3dhttps%3a%2f%2petera
ccount.rapdata.com/&Contract=2
Ugh! You might say. But, such a convoluted value is really NOT beyond
the realm of possibility for machine-based logon . We have all seen what
Microsoft Word conversion to HTML did to the use of HTML markup, making
it unreadable by humans!
Now, if we follow the Important Note in the spec, the Consumer shall
apparently follow the redirects caused by that URL's resolution. As the
resource at the URL happens to cause (for authorized users) an
IDP-initiated SAML flow (via, say, the REDIRECT binding), a series of
redirects will occur eventually landing on a site for the URL
peteraccount.rapdata.com <http://www.peteraccount.crsdata.com> etc (if
the DNS registrations and SAML trust relations all hold up, at
evaluation time).
>From what I can determine, once https delivers the HTML document
(according to and satisfying the Consumer's SSL key management policy)
the "final URL" is https://peteraccount.rapdata.com/ . This string,
furthermore, is the "final, canonicalized URL" ( in the absence of an
openid.delegated link field value in the HTML document delivered over
https). This is thus the "End User's Identifier".
------------
Lets continue the thought experiment:-
Lets say the that openid.server link value is
https://login.rapmlsstg.com/sp/SsoHandler.aspx. We can note that this
URL has little formal relationship to the End User's Identifier
https://peteraccount.rapdata.com/
Nevertheless, the consumer can now expect to find an OP Provider
listener at that link value URL. If this is true, the consumer agent and
provider agent then engage in the "OpenID Authentication Protocol".
In the course of completing the protocol, the provider agent will
normally be required to perform BY MEANS BEYOND THE SCOPE OF OPENID AUTH
SPEC, user authentication - before it supplies the "cryptographic proof"
that a user controls the End User's Identifier. After following some
series of locally-defined redirects to a form-login page, users might
perform this by completing the action of typing in a correct
username/password combination.
Is there any flaw in my understanding, in any of the above?
Are the example's "complying"?
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070708/ce695719/attachment-0001.htm>
More information about the general
mailing list