<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">email is not the identifier that openID provides.<div><br></div><div>openID provides a claimed_id URL that is the user identifier.</div><div><br></div><div>Some providers provide a email via attribute exchange or sreg. </div><div><br></div><div>That may or may not be verified unless you know the provider and their verification policies never use the email as the primary identifier.</div><div>email addresses are also potentially recycled causing other problems.</div><div><br></div><div>I have seen RP create huge security holes by treating email as the asserted identifier.</div><div><br></div><div>Use the claimed_id please.</div><div><br></div><div>John B.<br><div><div>On 2011-06-01, at 6:37 PM, Arthur Goldberg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
Andrew<br>
<br>
Thanks for your reply.<br>
<br>
Yes, only programs interact with the backend WebAPI.<br>
<br>
Without OpenID the backend would store userid/passwd and support a
login function (over a secure connection) that took userid/password
and responded with either Fail or Success with a Nonce which it
generates for the user. Data access operations would take a Nonce,
and succeed or fail, depending on whether the user holding the Nonce
had rights to the data.<br>
<br>
The frontend would present a login screen, call the login function
on the backend, report the result to the user, and, if the login
succeeds save the Nonce. Subsequent data access requests by the user
would carry the Nonce.<br>
<br>
So you're saying that my frontend should run OpenID (be a relaying
party) and then be a special (have a shared secret) client to the
backend. Then the backend would need another command, register(
email, Nonce ), which it would only accept from any special client,
and which would register the Nonce as belonging to the user with the
given email (email is the userid, because that's what OpenID
provides). <br>
<br>
That's OK, but then only special clients can register with the
backend. What I didn't describe below is that user programs can
interact with the backend.<br>
user program <-> Back-end<br>
<br>
Given this design, it seems the best way for 'user program' to
access the back-end would be for the frontend to display the Nonce
to a securely-connected Browser and have the user copy&paste the
Nonce into 'user program' which would use it in data access
requests. But the user program cannot login automatically, because
it isn't a special client.<br>
<br>
BR<br>
A<br>
<br>
On 6/1/11 5:27 PM, Andrew Arnott wrote:
<blockquote cite="mid:BANLkTik4Z=t=4QKN3baedP8fm2qyYH9OgQ@mail.gmail.com" type="cite">
<pre wrap="">From your diagram it looks like the user never interacts with the
backend. You should probably preserve that.
Ask yourself the question: How would I do this without OpenID? If you
would accept a password, which server would present the HTML, and
accept the form POST, that asks the user for the password? If that's
the frontend, then you should do OpenID on your frontend as well.
Whether you use OpenID or username/password, ultimately what that
interacting server should do is assign an auth cookie to the browser,
and then tell the backend (which trusts the frontend) which user it is
impersonating. So in the case where the frontend is authenticating
the user, switching to OpenID shouldn't impact how the front and back
ends talk to each other at all.
--
Andrew Arnott
"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 Wed, Jun 1, 2011 at 1:46 PM, Arthur Goldberg <a class="moz-txt-link-rfc2396E" href="mailto:goldberg@cbio.mskcc.org"><goldberg@cbio.mskcc.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello
We would like to use OpenID authentication.
But our system has two servers, not one: a Front-end provides analysis and a
user interface, and a Back-end stores the data in a database and makes it
available through a Web API.
Thus, a user interacts with our system like this:
Browser <-> Front-end <-> Back-end with Web API
It seems that an easy way for us to use OpenID would be for the Back-end to
act as a Relaying Party and the Front-end to simply forward all OpenID
protocol requests between the Browser and the Back-end. That is,
the Front-end will perform 7.1. Initiation (sections from OpenID
Authentication 2.0), and keep that connection open
the Front-end will forward the OpenID URL provided by the user to a service
on the Back-end, and keep that connection open
the Back-end then runs the OpenID protocol; the Front end acts as a tunnel
between the Browser and the Back-end; it forwards all responses it receives
from the Back-end to the Browser, and forwards all responses it receives
from the Browser to the Back-end (it would be easy to do this with raw
socket level code; I'm unsure of how to do it inside a servlet)
When the Front-end receives a Positive Assertion or a Negative Assertion it
will
Does this make sense?
Is there a better way to accomplish what I want to do?
Does an existing implementation in Java exist that I could use?
Thanks
A
--
Senior Research Scientist
Computational Biology
Memorial Sloan-Kettering Cancer Center
cBio Cancer Genomics Portal
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@lists.openid.net">general@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a>
</pre>
</blockquote>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Senior Research Scientist<br>
Computational Biology<br>
Memorial Sloan-Kettering Cancer Center<br>
<a href="http://www.cbioportal.org/">cBio Cancer Genomics Portal</a></div>
</div>
_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-general<br></blockquote></div><br></div></body></html>