<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks John<br>
<br>
Actually, I wrote 'email' to be provocative. Thanks for eating the
bait.<br>
I know that the claimed_id is the user identifier and should be
used. But our use-case makes that problematic.<br>
A scientist sends us some data and a list of people who can access
the data. We can easily ask them for a list of email addresses
identifying the people. But a list of claimed_ids is awkward. Few
non-geeks have of heard of OpenID. And they don't know their
claimed_ids. And they might have trouble finding their id. For
example, here's <a
href="http://help.yahoo.com/l/us/yahoo/edit/open_id/oid-02.html">instructions</a>
on finding a yahoo id, but I cannot find a way for someone to learn
their Google id.<br>
Also, yahoo provides two ids for me, one with my name and one that's
a random string. Which one would I need to tell someone to send us?<br>
<br>
Here's another approach. Can't say I love it, however. Make a
special obscure URL which will register someone on our site as a
user of a particular data set via an OpenID login. Then send the URL
securely to the scientist who'll email it to all the people who
should access the data, who'll login hopefully before the obscure
URL expires.<br>
<br>
Is there a better way?<br>
<br>
Regards<br>
Arthur<br>
<br>
On 6/1/11 7:49 PM, John Bradley wrote:
<blockquote
cite="mid:755E40CE-A7F6-40FA-AB08-B5E4E001ED6B@ve7jtb.com"
type="cite">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 moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:general@lists.openid.net">general@lists.openid.net</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="http://www.cbioportal.org/">cBio Cancer Genomics
Portal</a></div>
</div>
_______________________________________________<br>
general mailing list<br>
<a moz-do-not-send="true"
href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-general">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
</blockquote>
</div>
<br>
</div>
</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>
</body>
</html>