Re: Passwords

Hi all,

I'm glad that everybody agrees on the idea to have some migration process requiring everybody to change their password and confirm their details. I'd like to have a 'one shot' roll out, but it might make us push too far the deployment.

Here's answers to questions people either asked explicitly or not about SSL and the new login system.

I know its a long email, but I wanted to answer all questions and explain my scope and the limitations I have to deal with.

TL;DR, I agree it'd be nice to have full roll-out of a new accounts system and the whole site under SSL, but we have some blockers such as; politics, fees (maybe), and more work involved. My current focus is the actual implementation of SSO, the authentication service, creating the missing components to connect to it, and the accounts migration.

<aside>
If you are new to the project and want to read more about our infrastructure, you might want to see the blog post about our setup[3] that Ryan Lane, my predecessor, wrote.
</aside>


# The new SSO and SSL

Making happen SSO has already many requirements and [#SSL across the site] will impact many layers that would require more work and would have me divert my focus from priorities.

But it doesn't mean that we won't use SSL for the new authentication server. In fact the new system will be under SSL, but it'll also provide us an OAuth service from which we'll be able to connect other components.


# Rolling out the accounts

The way I see how we rollout the new accounts system across the site is to create extensions for each service (MediaWiki, Bug Genie, Annotator, etc). Each extension would override any accounts functionality and delegate authentication to the new accounts service through OAuth. 

Provided a person doesn't follow up to the email we are going to send, they'll be handled automatically. Besides, this kind of feature is generally part of any SSO deployment.

What I'd like to do is that we use SendGrid to send the announcement to all the accounts email. I know we have a mailing system, but I'd like to leverage SendGrid's stats to see the bounces and help us filter the real accounts from the spam.

Something that is yet to organize and that is currently not a priority for me.


# SSL across the site

Unfortunately, we cannot replace all 'http://' to '//' and force everybody to use SSL. 

It'll need some more work that goes outside of my current focus.

For starters, we do not have SSL virtualhosts —meaning that many files will get 404—, but in addition, we'd send all requests outside of our Caching+CDN, hit directly our backend servers.

Since our infrastructure has more than one web server, that our visitors are from across the globe, and that the heaviest load comes from dynamic pages; having a Cache+CDN such as Fastly is an asset.

If we want to serve SSL across the site, we have a few issues:

1) More than one server/web applications involved, and
2) We are behind a third party CDN provider, or
3) Have our own local HTTP caching layer and stop using Fastly


1)  More than one server/web applications involved

Our current sever setup cannot serve both over SSL and non SSL without having to do more configuration on Fastly side.

I'm not saying its not considered but it won't help me ship SSO in a reasonable timeframe.



2)  We are behind a third party CDN provider

To have SSL for all the site behind Fastly will require us to:
- Install SSL certificates on their side
- Install SSL certificate between them and our backend servers
- Configure all services to have both http and https equals

As I said, since we are behind a CDN+Varnish. It means that we will have to have a SSL certificate installed at Fastly, then, one between Fastly and our backend servers.

They would be our trusted "man in the middle". Its scary, but it has advantages that are worthwhile (see [#Fastly, and more on SSL] to see what I mean). 

Also, we will have to see with Fastly about our service package. Maybe it would cost more money to have SSL from our top level domain, if can be included in our service package and/or part of the open source account package we have with them [0].

This is why i'm not working on this at the moment.


3)  Have our own local HTTP caching layer and stop using Fastly

We can counter my argument about the need of a CDN and set in place our own HTTP caching with Varnish/NGINX configured with our own SSL certificates without an external CDN.

We're not the only ones who thought about it, this article[2] describes their decision process.

All of this is possible but still doesn't invalidate that i'd have to change many layers in our servers configuration and its not helping me ship SSO either.



# Fastly, and more on SSL

The benefit we have with them is that they are both providing CDN and HTTP Caching through Varnish, but there are other benefits.

- We can switch backend servers without waiting DNS propagation
- It is a separate service from our servers
- It'll be easy to serve backends from both provider sites (i.e. DreamHost and somewhere else)

... and that we have visitors from across the globe fastly feels like a good fit for us.

I'd, obviously, prefer that we have everything behind a CDN AND Varnish AND over SSL. Unless we revise our server setup strategy.


[0]: http://www.fastly.com/pricing#bandwidth_pricing
[2]: https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/
[3]: http://blog.webplatform.org/2012/10/building-web-platforms-infrastructure/


If you have questions that I haven't answered, do not hesitate  :)

Renoir
~

On 2014-04-25, 8:07 PM, Jen Simmons wrote:
> I think if we simply ask all users to reset their password as part of a big
> announcement of single-sign-on — that'll be fine. Could actually be very
> good, since it'll bring to mind for everyone that now they have *one*
> password for all WPD stuff. Anyone who currently has multiple logins &
> passwords — which might not match — those people could easily be confused
> after SSO is deployed if there is no reset required. Heartbleed will make
> this less painful. Everyone's used to getting password resets for security
> reasons right now. I think we shouldn't just make it seem like a security
> thing, however. We should use it as a Big Announcement.
>
> The password reset will happen *after* the rollout? Only once? I think that
> would be ideal.
>
> It would be great if we could get metrics on this as it happens. How many
> users do reset vs how many don't?? If we can.
>
> Jen
>
> Jen Simmons
> designer, consultant and speaker
> host of The Web Ahead
> jensimmons.com
> 5by5.tv/webahead
> twitter: jensimmons <http://twitter.com/jensimmons>
>
>
>
> On Fri, Apr 25, 2014 at 7:57 PM, Doug Schepers <schepers@w3.org> wrote:
>
>> Hi, folks–
>>
>> Renoir is in the middle of setting up a new accounts system to enable
>> Single Sign-On (SSO) across the different applications for WebPlatform
>> (starting with the wiki and the annotation system, then later the blog and
>> the issue tracker). This new system should also be somewhat more secure and
>> easier to manage. We will likely deploy the new system in May.
>>
>> One of the decisions we have to make is how to handle the passwords of
>> existing accounts; the question is whether we attempt to import and manage
>> the passwords automatically (there are some technical challenges there,
>> because passwords are stored encrypted), or if we can simply ask users to
>> reset their passwords.
>>
>> Pros:
>> 1) it's less work for Renoir, giving him more time to solve other problems
>> 2) in the wake of the Heartbleed bug, it's good practice for people to
>> reset their password
>> 3) it will give us a chance to remind and reconnect people to the project
>> (by emailing them to ask them to reset their password)
>> 4) it's a relatively small and easy thing to ask people to do
>> 5) it gives us the opportunity to weed out some spambots
>> 6) (anything else??)
>>
>> Cons:
>> 1) it is more inconvenient for our users
>> 2) some people may be confused by the change
>> 3) some people might be annoyed by us "spamming" them with an update
>> request
>> 4) anything else??
>>
>> As you can see, currently I favor asking our users to change their
>> passwords. I had a hard time coming up with cons, which is why I'm asking
>> y'all in the community, to make sure I'm not missing anything.
>>
>> Thoughts?
>>
>> Thanks-
>> -Doug
>>
>>

-- 
Regards,

Renoir Boulanger  |  Developer operations engineer
W3C  |  Web Platform Project

http://w3.org/people/#renoirb  ✪  https://renoirboulanger.com/  ✪  @renoirb
~