IdP for uncontrolled domain

[Tim Kuijsten]

I was wondering if it will be possible to run your own Identity provider
for a domain you have not in control.

I'm developing an app for an enterprise and will setup the user accounts
manually (the users should not register themselves). I was wondering if
I could replace the normal login/authentication procedures I would write
myself where I give every user a login with the e-mail address they use
in their company, with a BrowserID implementation (given I can run my
own IdP and I understand that code still has to be published [1]).

So my question, will it be possible to setup BrowserID, run my own IdP
and create logins like us...@bigenterprise.org without bothering the
IT-staff of bigenterprise.org about anything (like DNS changes or make
them run software like an IdP)?

I suspect because of some verifications built in the protocol, this will
not be possible.

[1]
http://mail-archives.apache.org/mod_mbox/couchdb-user/201112.mbox/%3CCA%2BaD3u10w0xZNY2RLJVRHKmewsXPpz7pW6x7ZTJ%2BRk_nZmLUnw%40mail.gmail.com%3E

[Ben Adida]

On 12/26/11 4:59 AM, Tim Kuijsten wrote:
> I was wondering if it will be possible to run your own Identity provider
> for a domain you have not in control.

You'll need at least one static file served at a well-known URL at that
domain, or maybe a DNS record (we haven't solidified that part of the
protocol yet). But you need *something* for the protocol to know that
the domain bigenterprise.com delegated its authority to someone else.

-Ben

[Peter Williams]

That's very hammar stack. Im seeing host-metas, now. For the use case mentioned, it should remind one of 1990s era virtual hosting of sites, on web servers hosted at ASPs, to which one then wanted to add https certs selectively (and from different CAs). Does one have, for example, a "static file" from an authority? Should that be a cert with a wildcard pattern in the server name/extension? This is of course what drives site hosting, today. Today, in the Azure cloud (a PAAS offering recall), one simply uploads a .p12 file to the virtual machine monitor. as each VM is instanced in one of the n data centers around the world using (trusted) SAN replication or referencing, the installed .p12 keying material is copied ...as the cert store into which it was loaded is copied. But, there used to be ferocious debates in the CA world on whether server admins with EE server certs should be able to mint an additional cert on "their" chain, enabling "delegation" to the hosting party of the desired server endpoint. Many folks on government were hell bent on never allowing "ordinary" parties to be CAs, under any circumstance. It was VERY dogmatic. it spelled the end for the easist way - which was to use the X.509 control that minted the party's server cert with the basic Constraints extension marking it as a CA, entitled to issue only 1 more level of cert to a chain, and in a certain namespace (there own!). But, it violated the desire for social control over key management. ASPs tended to be large companies, who were and no doubt are typically highly influenced by a big of negative marketing from "authorities", represented by conservative auditors, board members, the local police commander, etc etc. The net result was nothing improved; and PKI slowly became associated with stodginess, fear, hush hush, and, "untrustworthiness". Whatever you did, you MIGHT be deemed inapprorpriate at a "social level". The protocol design needs to have a strong social model, so it doesnt fall into the same trap. The design needs to be driven by social policy - that is outward looking, adventurous, and even a bit radical. These are JUST there to be counterweights to the conservativeness that, in key management AT SCALE, leads to distrust. > Date: Mon, 26 Dec 2011 09:31:35 -0800
> From: b...@adida.net
> To: dev-id...@lists.mozilla.org
> Subject: Re: IdP for uncontrolled domain

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

[Tim Kuijsten]

Op 26-12-11 18:31, Ben Adida schreef:

> On 12/26/11 4:59 AM, Tim Kuijsten wrote:
>> I was wondering if it will be possible to run your own Identity provider
>> for a domain you have not in control.
>
> You'll need at least one static file served at a well-known URL at that
> domain, or maybe a DNS record (we haven't solidified that part of the
> protocol yet). But you need *something* for the protocol to know that
> the domain bigenterprise.com delegated its authority to someone else.

Understandable, but unfortunately unfeasible for the current job I'm
working at. Rolling out my own auth system and creating usernames like
us...@bigenterprise.com and sending passwords overthere is easier than
asking the enterprise wide IT-staff to do something (anything) for a
small subdivision who have build a system by externals. A system that
will be small in the beginning but we hope it will be used by the whole
enterprise later on (so as a small party we need as less work done by
the bigenterprise.com IT-staff as possible, none actually).

Just to give a description of a potential use case.

Tim

[Michiel de Jong]

thinking out loud:

we have a similar situation as you, where we're rolling out remote storage
to all students and staff of all Dutch universities and colleges. So a big
project, and we can't talk to the central IT department of each individual
university; exactly like in your situation. We considered the option of
'spiking' our verifier to pretend that the delegation records exist, even
if it doesn't. If you have access to LDAP or something, then that might
work for you, but it would confuse users, because other verifiers would not
have the same patch, and will reject users that you do not reject. Also,
spiking the verifier sounds like a very dodgy patch to a security system -
unexpected things might go wrong; best not to experiment with its internals.

So our current idea is to just fall back to SMTP for universities who have
not yet done the little job of setting up the delegation. Yes, it's
temporarily centralized then, but it allows us to launch quickly and it's
only as a sort of 'legacy support' for those IT departments who have not
yet delegated to us - which is little work for them - or taken their own
initiative in setting up BrowserId for their user base.

In your case maybe you could fallback to SMTP, but maybe with your own
secondary (so "competing" with browserid.org), which exists only inside
your intranet. the downside of that is that people have to create an
account on your secondary, even if they already have an account at the 'de
facto' secondary, which is mozilla's browserid.org. but if having mozilla
in the loop is not an option for you, and you need something you can launch
quickly with, then it might be an option? or would this be a Bad Idea?

also when your system grows, you can still convince the Big IT department
to implement primary IdP support (which, if they take themselves seriously,
they would have to do at some point anyway once BrowserId begins to
snowball), and remove your intranet-internal secondary IdP, so it would
really only be a way to bootstrap browserid inside this intranet.

i hope i didn't say anything here which isn't true - as i said i'm just
thinking out loud here, please correct me :)


cheers!
Michiel

On Tue, Dec 27, 2011 at 6:37 PM, Tim Kuijsten <t...@slasa.us> wrote:

>
>
> Op 26-12-11 18:31, Ben Adida schreef:
>
> On 12/26/11 4:59 AM, Tim Kuijsten wrote:
>>
>>> I was wondering if it will be possible to run your own Identity provider
>>> for a domain you have not in control.
>>>
>>
>> You'll need at least one static file served at a well-known URL at that
>> domain, or maybe a DNS record (we haven't solidified that part of the
>> protocol yet). But you need *something* for the protocol to know that
>> the domain bigenterprise.com delegated its authority to someone else.
>>
>
> Understandable, but unfortunately unfeasible for the current job I'm
> working at. Rolling out my own auth system and creating usernames like
> us...@bigenterprise.com and sending passwords overthere is easier than
> asking the enterprise wide IT-staff to do something (anything) for a small
> subdivision who have build a system by externals. A system that will be
> small in the beginning but we hope it will be used by the whole enterprise
> later on (so as a small party we need as less work done by the
> bigenterprise.com IT-staff as possible, none actually).
>
> Just to give a description of a potential use case.
>
> Tim
>
>
>
>> -Ben

>> ______________________________**_________________
>> dev-identity mailing list
>> dev-id...@lists.mozilla.org
>> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>>
> ______________________________**_________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>

[Ben Adida]

On 12/27/11 3:37 AM, Tim Kuijsten wrote:
>
> Understandable, but unfortunately unfeasible for the current job I'm
> working at. Rolling out my own auth system and creating usernames like
> us...@bigenterprise.com and sending passwords overthere is easier than
> asking the enterprise wide IT-staff to do something (anything) for a
> small subdivision who have build a system by externals.

Yes, I certainly understand that. And Michiel provides one approach you
could take, though I agree with him that you will hit some pain points
if you "spike your verifier" (nice expression Michiel.)

So, as Michiel said: could you rely on secondary auth for now? Maybe by
prototyping primary auth on a subdomain you do control, e.g.
https://smalldivision.bigenterprise.com with
us...@smalldivision.bigenterprise.com?

-Ben

[Tim Kuijsten]

Op 27-12-11 14:53, Michiel de Jong schreef:

> thinking out loud:
>
> we have a similar situation as you, where we're rolling out remote
> storage to all students and staff of all Dutch universities and
> colleges. So a big project, and we can't talk to the central IT
> department of each individual university; exactly like in your
> situation. We considered the option of 'spiking' our verifier to pretend
> that the delegation records exist, even if it doesn't. If you have
> access to LDAP or something, then that might work for you, but it would
> confuse users, because other verifiers would not have the same patch,
> and will reject users that you do not reject. Also, spiking the verifier
> sounds like a very dodgy patch to a security system - unexpected things
> might go wrong; best not to experiment with its internals.
>
> So our current idea is to just fall back to SMTP for universities who
> have not yet done the little job of setting up the delegation. Yes, it's
> temporarily centralized then, but it allows us to launch quickly and
> it's only as a sort of 'legacy support' for those IT departments who
> have not yet delegated to us - which is little work for them - or taken
> their own initiative in setting up BrowserId for their user base.
>
> In your case maybe you could fallback to SMTP, but maybe with your own

> secondary (so "competing" with browserid.org <http://browserid.org>),

> which exists only inside your intranet. the downside of that is that
> people have to create an account on your secondary, even if they already
> have an account at the 'de facto' secondary, which is mozilla's

> browserid.org <http://browserid.org>. but if having mozilla in the loop

> is not an option for you, and you need something you can launch quickly
> with, then it might be an option? or would this be a Bad Idea?

With fallback to SMTP I assume you mean the classic "send e-mail with a
link to verify account" way to register people. Is this baked into
BrowserID? Furthermore, this idea of a secondary, how does a secondary
differ from a primary. From a practical point of view it sounds like any
party can play some sort of primary role for domains that haven't
implemented BrowserID yet, so it does sound like a solution.

>
> also when your system grows, you can still convince the Big IT
> department to implement primary IdP support (which, if they take
> themselves seriously, they would have to do at some point anyway once
> BrowserId begins to snowball), and remove your intranet-internal
> secondary IdP, so it would really only be a way to bootstrap browserid
> inside this intranet.
>
> i hope i didn't say anything here which isn't true - as i said i'm just
> thinking out loud here, please correct me :)
>
>
> cheers!
> Michiel
>
> On Tue, Dec 27, 2011 at 6:37 PM, Tim Kuijsten <t...@slasa.us
> <mailto:t...@slasa.us>> wrote:
>
>
>
> Op 26-12-11 18:31, Ben Adida schreef:
>
> On 12/26/11 4:59 AM, Tim Kuijsten wrote:
>
> I was wondering if it will be possible to run your own
> Identity provider
> for a domain you have not in control.
>
>
> You'll need at least one static file served at a well-known URL
> at that
> domain, or maybe a DNS record (we haven't solidified that part
> of the
> protocol yet). But you need *something* for the protocol to know
> that

> the domain bigenterprise.com <http://bigenterprise.com>

> delegated its authority to someone else.
>
>

> Understandable, but unfortunately unfeasible for the current job I'm
> working at. Rolling out my own auth system and creating usernames

> like us...@bigenterprise.com <mailto:us...@bigenterprise.com> and

> sending passwords overthere is easier than asking the enterprise
> wide IT-staff to do something (anything) for a small subdivision who

> have build a system by externals. A system that will be small in the
> beginning but we hope it will be used by the whole enterprise later
> on (so as a small party we need as less work done by the

> bigenterprise.com <http://bigenterprise.com> IT-staff as possible,

> none actually).
>
> Just to give a description of a potential use case.
>
> Tim
>
>
>
> -Ben

> _________________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> <mailto:dev-id...@lists.mozilla.org>
> https://lists.mozilla.org/__listinfo/dev-identity
> <https://lists.mozilla.org/listinfo/dev-identity>
>
> _________________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org <mailto:dev-id...@lists.mozilla.org>
> https://lists.mozilla.org/__listinfo/dev-identity
> <https://lists.mozilla.org/listinfo/dev-identity>
>
>

[Tim Kuijsten]

Op 27-12-11 16:07, Ben Adida schreef:

> On 12/27/11 3:37 AM, Tim Kuijsten wrote:
>>

>> Understandable, but unfortunately unfeasible for the current job I'm
>> working at. Rolling out my own auth system and creating usernames like

>> us...@bigenterprise.com and sending passwords overthere is easier than

>> asking the enterprise wide IT-staff to do something (anything) for a
>> small subdivision who have build a system by externals.
>

> Yes, I certainly understand that. And Michiel provides one approach you
> could take, though I agree with him that you will hit some pain points
> if you "spike your verifier" (nice expression Michiel.)
>
> So, as Michiel said: could you rely on secondary auth for now? Maybe by
> prototyping primary auth on a subdomain you do control, e.g.
> https://smalldivision.bigenterprise.com with
> us...@smalldivision.bigenterprise.com?

Unfortunately everybody in smalldivision uses us...@bigenterprise.com, so
it's less desireable. The role of this secondary and how it relates to a
primary is still a bit unclear to me.

Essentially I would like to run my own browserid.org but I see you
advise against that in a different thread ;-)

>
> -Ben

[Ben Adida]

On 12/27/11 8:07 AM, Tim Kuijsten wrote:
>
> Unfortunately everybody in smalldivision uses us...@bigenterprise.com, so
> it's less desireable. The role of this secondary and how it relates to a
> primary is still a bit unclear to me.

We would prefer a world where every domain certifies its own users.
That's ideal. But we know we can't get there immediately. Even in the
long run, some domains will never implement BrowserID. So a secondary
authority is needed to fill that gap (which we expect will become
significantly smaller over time.)

For now, BrowserID is built with just Mozilla as the secondary
authority. The reason is that multiple secondaries makes things
difficult: how do you know which ones to trust? We also don't want to
develop a CA model that resembles that of SSL, where anyone can certify
anyone else and it becomes unmanageable.

So, my recommendation is still: use https://browserid.org to certify
your users with Mozilla as a secondary. In parallel, prototype the
primary authority approach: we'd be happy to help you think this through.

> Essentially I would like to run my own browserid.org but I see you
> advise against that in a different thread ;-)

You can do this, but, as I'll explain in greater detail in the other
thread, your biggest risk is that you'll be isolated from the rest of
the BrowserID ecosystem.

-Ben

[Peter Williams]

Let me put it pretty bluntly. I cannot adopt an american-controlled root formally (its politically impossible). I have to be seen to adopt a UK root. This is the same issue as asking the typical american to adopt a Euro root, or other "foreign" root. It produces "adoption issues". No amount of "future" assurances about devolution... will address this "social issue". This (rather stupid co-nationalistic) topic was solved in the CA era (1996) vs the PKI era (2000+) by the likes of BT NOT becoming a formal subordinate/delegate of VeriSign in the cert chain sense but by becoming an "API-based reseller" of a central minting service (US based, as it happened). Folks did cross equity ownership, joint ventures, and joint this and that - to otherwise engender trust. Its a commercial (not military) space, after all. At that point, the issue went away (and it was business as usual, with the US firm that actually made the market running the show). Yes, BT has roots in the browser (that noone uses), for the rainy day. It even leases them to other telcos, for their rainy day. Such rainy day docs and prep are like a BP safety report, issued by the LA state oil board. As you scale up and have greater potential impact from systemic compromise, you need to do ever more cryptopolitics. It wont work till you do.> Date: Tue, 27 Dec 2011 08:58:57 -0800
> From: b...@adida.net
> To: t...@slasa.us

> Subject: Re: IdP for uncontrolled domain

> CC: dev-id...@lists.mozilla.org

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