Closed Bug 731856 Opened 10 years ago Closed 9 years ago

mozilla.com needs to host /.well-known/browserid after deployment of Mozilla IdP

Categories

(Infrastructure & Operations :: IT-Managed Tools, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ozten, Assigned: nmaul)

References

Details

(Whiteboard: [waiting][identity])

We're building a BrowserID Primary Identity Server for mozilla.com email addresses.

What does this mean?
https://github.com/ozten/vinz-clortho/blob/master/README.md

We need host this "/.well-known/browserid" file on dev, stage, and production mozilla.com instances.

It's file contents are static and different for each environment.

We won't want to deploy this until right after the IdP project has shipped.
Blocks: 728382
We'll coordinate as time get's closer, but project management timeline for this project is at
https://wiki.mozilla.org/Identity/BrowserID/VinzClortho#Project_Management
Component: www.mozilla.org/firefox → www.mozilla.org
What is mozilla.com's dev environment ( or stage if there isn't one)?

Is it available over https?
Doh, scheduling a meeting with jakem to discuss hosting...

mozilla.com now redirects to mozilla.org.

The BrowserID protocol for @mozilla.com email addresses will try to talk to
https://mozilla.com/.well-known/browserid

@jakem mentioned https://www.mozilla.com/.well-known/browserid as being more redundant and that a sub-domain is easier to scale.

We'll need to keep our mozilla.com SSL cert in good standing, even though no visual website depends on it. This is a risk to Mozilla.com being a primary IdP.
Doh, scheduling a meeting with jakem to discuss hosting...

mozilla.com now redirects to mozilla.org.

The BrowserID protocol for @mozilla.com email addresses will try to talk to
https://mozilla.com/.well-known/browserid

@jakem mentioned https://www.mozilla.com/.well-known/browserid as being more redundant and that a sub-domain is easier to scale.

We'll need to keep our mozilla.com SSL cert in good standing, even though no visual website depends on it. This is a risk to Mozilla.com being a primary IdP.
@jakem worked out a solution in https://etherpad.mozilla.org/well-known-limitations

I'll file additional bugs for dev and stage environments.
Assignee: nobody → server-ops
Component: www.mozilla.org → Server Operations: Web Operations
Product: Websites → mozilla.org
QA Contact: www-mozilla-com → cshields
Version: unspecified → other
Please don't implement this ticket until Vinz Clortho is live in production.

I'll update this bug to coordinate.
I have done some work on this, and it's usable now with an /etc/hosts tweak. SSL will return the wrong cert right now, but that can be fixed.

All the notes in the Etherpad apply- this is a single-IP, non-multi-hosted config. It's a new VirtualHost container on bedrock, so we can easily change the IP from SCL3 to PHX1 or vice versa, and it should work in either place... but given the BrowserID protocol as currently defined, we can't really make it multi-hosted without major DNS changes (basically: move mozilla.org to Dynect).

The main issue is that this cannot go live until the app at intranet.mozilla.org is also complete and in-production, or @mozilla.com BrowserID logins will break.
Assignee: server-ops → nmaul
Whiteboard: [qa?]
Whiteboard: [qa?] → [waiting][identity]
Is this abandoned now? Last repo documented no longer exists, current repo hasn't been touched in 7 months, no significant activity on this bug since May.
We still are going to do this project, but we've de-prioritized it from our queue compared to Beta2, etc.
jakem - We're looking at putting this onto our queue for Q3.

Who is the point person I should talk to, to revive this project?

Thanks for your help.
Jake?  We still doing this?  I've sent mail to you asking if this is still teh appropriate bug to track Mozilla IdP for @mozilla.com addresses, but have had no reply.

Please let us know if there's anything that needs to be done to unblock this deployment.
Kark,

Jake is on PTO right now, I will try to answer and let him backfill once he is back in the office.

As I understand it we do not have the information we need to proceed with this as per comment #9 as well as the intranet.m.o question from c#7.

This bug is a fine place to coordinate this project. We just need to know what the state of the project is, is what the timeline looks like, where we can find the code, and who is the developer on point for the individual pieces of the project. Also if there is any up to date information on a wiki please post the links here.

If we need to schedule a meeting for later in the week to discuss that might be a good idea as well.

Once we get an idea of your timeline along with the time we think we will need to do our portion of the work we will be in a position to determine where we can fit it into our schedule.

Thanks
Assignee: nmaul → server-ops-webops
Component: Server Operations: Web Operations → WebOps: IT-Managed Tools
Product: mozilla.org → Infrastructure & Operations
QA Contact: cshields → nmaul
Karl with an L that is, sorry for the typo :)
Hi, 



App code repo: https://github.com/mozilla/vinz-clortho
Deploy code repo: https://github.com/mozilla-services/svcops-oompaloompas/tree/master/apps/mozilla-idp

Deployment docs: 
https://mana.mozilla.org/wiki/display/SVCOPS/Mozilla+IDP

State of the project:

- 4 servers in production. Already powering @mozillafoundation.org
- ready for @mozilla.com as well. 
- current deployed version: https://github.com/mozilla/vinz-clortho/tree/train.2013_07_09.12.49.33

I am the dev/ops contact for any changes / issues that need to be resolved.
IdP for @mozilla.com is deployed! I believe there is no more work to do here. :)
Assignee: server-ops-webops → nmaul
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.