Re: One Site: Multiple domains

[Shane Tomlinson]

Hi Larry,
Thanks for posting this to the list. We have seen this problem in the past,
have tossed around ideas, but we have never come to an agreement for a
solution.

Webmaker and Popcorn, two projects from Mozilla Foundation, have run in to
this same problem. Their solution was to embed a common iframe, served
from a common host, to both sites. The iframe takes care of authentication
for both sites. A common iframe shared across sites is a heavyweight
solution, but it works.

9 or so months ago, I experimented with SSO as a full feature of Persona[1].
The experiment was to declare a new parameter, ssoDomains, when calling
navigator.id.get or navigator.id.request. ssoDomains was a list of domains
that, if the user is signed in to "this" site, is also signed into "those"
sites.

Again, this was quick experiment to see if it could be done. The API was
not well thought through, and the feature never went anywhere.

A user of the Wordpress Persona plugin ran into this problem last week [2].

I would like to revive this experiment if there is interest.

There seem to be two types of SSO:

* cross-domain (signing in to a.com also signs you into b.com)
* intra-domain/cross-subdomain SSO (signing into a.com also signs you
into news.a.com or signing into news.a.com also signs you into
blog.a.com)

A major issue is how two domains (or subdomains) establish a relationship.
Thunder and I talked once of establishing a common "realm" that each party
subscribes to.

Think of a realm as an association of sites. A site declares which realm
it belongs to. A central authority for each realm publishes a list of sites
that it believes belong to it. This means that sites have to cooperate for
there to be a link between them and one sided relationships cannot be
created.

The idea is that RPs declare, in their call to navigator.id.get
or navigator.id.request, a realm to which they belong. The realm declaration
points to an https URL, the endpoint of that URL is a JSON document that
declares which RPs are part of the realm and their common TOS/PP agreements.

This type of solution fits well for cross-domain SSO but I wonder if for
intra-domain/cross-subdomain sso if there is a simpler solution.

Could all RPs on one domain (*.a.com) declare a regular expression or a list
of subdomains the sign in is valid for?

For example:

subdomains: "*.a.com"

or

subdomains: ["login.a.com", "blog.a.com", "admin.a.com"]


What do others think?

Shane

==============

[1] - https://github.com/shane-tomlinson/browserid/tree/sso
[2] -
https://github.com/shane-tomlinson/browserid-wordpress/issues/18#issuecomment-18898750

On 04/06/2013 14:23, Larry Salibra wrote:
> Hi all,
>
> I'm considering implementing persona in a refresh of our product and have
> run into a problem with subdomains and the audience parameter when
> verifying identity assertions.
>
> The current watch browserid spec doesn't allow sign on state to be
> maintained across subdomains - a common practice supported by wildcard
> cookies.
>
> A user already logged in to example.com would prompted by the browser to
> select a new identity and log in again at subdomain.example.com. Imagine
> if news.google.com asked to you log on again right after you logged in to
> google.com. Pretty horrible user experience.
>
> According to stomlinson on #identity, two possible far from ideal
> workarounds are:
>
> 1) use the navigator.id.get API or
> 2) embed an iframe in every page that is always from the same domain. The
> iframe then takes care of all authentication related activities.
>
> Are there any better solutions?
>
> Since most web apps use cookies to remember log in state, Should "audience"
> be more restrictive than domain attribute of cookies?
>
> Thanks,
> Larry Salibra
>
> --
> Founder, Pay4Bugs
> http://www.pay4bugs.com
> Web: http://www.larrysalibra.com
> Twitter: http://twitter.com/larrysalibra
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

[Lloyd Hilaiel]

On Jun 10, 2013, at 8:38 AM, Shane Tomlinson <stoml...@mozilla.com> wrote:

> A major issue is how two domains (or subdomains) establish a relationship.
> Thunder and I talked once of establishing a common "realm" that each party
> subscribes to.
>
> Think of a realm as an association of sites. A site declares which realm
> it belongs to. A central authority for each realm publishes a list of sites
> that it believes belong to it. This means that sites have to cooperate for
> there to be a link between them and one sided relationships cannot be created.
>
> The idea is that RPs declare, in their call to navigator.id.get
> or navigator.id.request, a realm to which they belong. The realm declaration
> points to an https URL, the endpoint of that URL is a JSON document that
> declares which RPs are part of the realm and their common TOS/PP agreements.
>
> This type of solution fits well for cross-domain SSO but I wonder if for
> intra-domain/cross-subdomain sso if there is a simpler solution.
>
> Could all RPs on one domain (*.a.com) declare a regular expression or a list
> of subdomains the sign in is valid for?

As I sit down and think about this in the context of a single case, mozilla, I feel like a list or pattern could be a maintenance disaster. I can't see any design problems, because I feel like requiring a bi-directional expression of trust (in order for login to a.com to sign you into b.com, both sites must agree) is sufficient.

I tend to lean towards the original proposal, and think perhaps providing simply a single domain may be sufficient. Thus:

realm: 'mozilla.org'

… could be specified in parameters to .watch.

that suggests https://mozilla.org/.well-known/browserid-realm would exist. That file contains a list of domains that participate in the realm. A site must explicitly trust the realm by embedding the key in .watch(), and once complete, they are saying that they "delegate authority" to the controller of that domain to maintain the list of sites which participate in the SSO realm.. The controller then opts into the relationship by hosting the document and if a site is not listed, it may not participate in the realm.

I think this design makes globs an interesting feature, but not required for the feature's MVP (because you only must maintain the list in one place).

thoughts?

lloyd

[Jan Wrobel]

On Mon, Jun 10, 2013 at 4:38 PM, Shane Tomlinson <stoml...@mozilla.com> wrote:
>
>
> Could all RPs on one domain (*.a.com) declare a regular expression or a list
> of subdomains the sign in is valid for?
>

> For example:
>
> subdomains: "*.a.com"
>
> or
>
> subdomains: ["login.a.com", "blog.a.com", "admin.a.com"]

This is a tricky issue, because it is hard to tell if "login.a.com"
has control over other "*.a.com" domains. You could use a Public
Suffix List for this, but I'm afraid providers too often do not care
(or known) about a good practice of adding their shared domains to the
list. For example: Heroku's "herokuapp.com" domain was only very
recently added to the list, and it would be very unfortunate if any
Heroku hosted application that uses herokuapp.com domain could sign
users into other Heroku applications.

Cheers,
Jan

[Francois Marier]

On 11/06/13 02:38, Shane Tomlinson wrote:
> Webmaker and Popcorn, two projects from Mozilla Foundation, have run in to
> this same problem. Their solution was to embed a common iframe, served
> from a common host, to both sites. The iframe takes care of authentication
> for both sites. A common iframe shared across sites is a heavyweight
> solution, but it works.

By the way, I was talking to jbuck about this at JSConf and MoFo have
moved away from this iframe-based solution. They're now using a
postMessage-based mechanism to get their SSO.

I'm sure he would explain it better than me though :)

Francois

[Larry Salibra]

Hi all,

Sorry about the late reply. Been travelling behind the Great Firewall.

I agree with Lloyd - patterns or multiple lists in multiple places seems
bad for maintenance.

The realm / browserid-realm solution seems elegant from an implementation
standpoint.

Another issue is user interface. Does the user need to know that by
logging into a.com he is also logging in to b.com, c.com?

With regard to using the iframe solution: that effectively negates one of
the most attractive elements of Persona from the developer/company
perspective - being simple and easy to implement.

I don't think SSO is an edge case but a design flaw that needs to addressed
- it's hard to find a successful, widely-used web service that doesn't use
more than one domain, and logging in once per domain makes persona more
annoying and a worse user experience than the current status quo.

Please correct me if my understanding is wrong - I'm not nearly as well
versed in Persona and browersid as others on this list.

Best,
Larry

On Mon, Jun 10, 2013 at 11:24 PM, Lloyd Hilaiel <ll...@mozilla.com> wrote:

>
> On Jun 10, 2013, at 8:38 AM, Shane Tomlinson <stoml...@mozilla.com>
> wrote:
>
> > A major issue is how two domains (or subdomains) establish a
> relationship.
> > Thunder and I talked once of establishing a common "realm" that each
> party
> > subscribes to.
> >
> > Think of a realm as an association of sites. A site declares which realm
> > it belongs to. A central authority for each realm publishes a list of
> sites
> > that it believes belong to it. This means that sites have to cooperate
> for
> > there to be a link between them and one sided relationships cannot be
> created.
> >
> > The idea is that RPs declare, in their call to navigator.id.get
> > or navigator.id.request, a realm to which they belong. The realm
> declaration
> > points to an https URL, the endpoint of that URL is a JSON document that
> > declares which RPs are part of the realm and their common TOS/PP
> agreements.
> >
> > This type of solution fits well for cross-domain SSO but I wonder if for
> > intra-domain/cross-subdomain sso if there is a simpler solution.
> >

> > Could all RPs on one domain (*.a.com) declare a regular expression or a
> list
> > of subdomains the sign in is valid for?
>

> As I sit down and think about this in the context of a single case,
> mozilla, I feel like a list or pattern could be a maintenance disaster. I
> can't see any design problems, because I feel like requiring a
> bi-directional expression of trust (in order for login to a.com to sign
> you into b.com, both sites must agree) is sufficient.
>
> I tend to lean towards the original proposal, and think perhaps providing
> simply a single domain may be sufficient. Thus:
>
> realm: 'mozilla.org'
>
> … could be specified in parameters to .watch.
>
> that suggests https://mozilla.org/.well-known/browserid-realm would
> exist. That file contains a list of domains that participate in the realm.
> A site must explicitly trust the realm by embedding the key in .watch(),
> and once complete, they are saying that they "delegate authority" to the
> controller of that domain to maintain the list of sites which participate
> in the SSO realm.. The controller then opts into the relationship by
> hosting the document and if a site is not listed, it may not participate in
> the realm.
>
> I think this design makes globs an interesting feature, but not required
> for the feature's MVP (because you only must maintain the list in one
> place).
>
> thoughts?
>
> lloyd

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

--

[Jan Wrobel]

On Fri, Jun 21, 2013 at 5:44 PM, Larry Salibra <la...@pay4bugs.com> wrote:
> Hi all,
>
> Sorry about the late reply. Been travelling behind the Great Firewall.
>
> I agree with Lloyd - patterns or multiple lists in multiple places seems
> bad for maintenance.
>
> The realm / browserid-realm solution seems elegant from an implementation
> standpoint.
>
> Another issue is user interface. Does the user need to know that by
> logging into a.com he is also logging in to b.com, c.com?
>
> With regard to using the iframe solution: that effectively negates one of
> the most attractive elements of Persona from the developer/company
> perspective - being simple and easy to implement.
>
> I don't think SSO is an edge case but a design flaw that needs to addressed
> - it's hard to find a successful, widely-used web service that doesn't use
> more than one domain, and logging in once per domain makes persona more
> annoying and a worse user experience than the current status quo.

The way I understand this, is that sites can currently use Persona
with SSO, but they need to use the simpler navigator.id.get() API. So
it is not like these sites are not supported at all, they just can not
use the more powerful watch() API.

Cheers,
Jan