1273030 - Replace Persona with an alternative login solution on metrics and kibana dashboards

Status: RESOLVED FIXED

(Cloud Services Graveyard :: Metrics: Pipeline, defect, P2)

Description

[Ryan Kelly [:rfkelly]]

Persona will be decommissioned by the end of 2016, and I'm trying to ensure that all the work we need to do between now and then is captured under the following meta-bug:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1197381

I couldn't find an existing bug for migrating our metrics/kibana dashboards away from Persona, so I'm creating one.  If there is an existing bug, please link it under the above meta-bug and close this one out.

:whd, are you the best person to coordinate with for this work?

Comment 1

[Wesley Dawson [:whd]]

:rfkelly yes, I'm the best person to coordinate this work. We're thinking of rolling this into a broader q3/4 initiative to standardize access control to our various data sources. A particular sticking point that may or may not need to be addressed is how we grant access to partners outside Mozilla.

Comment 2

[Gene Wood [:gene]]

:whd,
In advance of the shutdown of Persona on November 30th[1], I was hoping to both find out what was planned, in regards to authentication, as well as offer up assistance and alternatives if needed.

If you'd prefer to just have a short discussion over Vidyo instead of writing a response, that's totally fine, either say so and I'll set it up or send a calendar invite to me to chat.

* Has an alternative authentication solution been selected for the site, if so what is the new planned auth solution?
* Is there a timetable and resources to complete the development of the change before November 30th?
* Would you like any help in coming up with an alternate auth solution? We have reference architectures for a handful of frameworks. If so, either schedule a Vidyo call with me or I will schedule one with you.
* How would you characterize your site's userbase? Do users that login currently consist only of people with Mozilla LDAP accounts? Do Mozilla contributors/community also currently log into the site? Does the general public log into the site?
* Since your currently using Persona for auth I'm assuming that your site doesn't have access to metadata about users stored in LDAP (e.g. first and last name) or access to LDAP group information of users (e.g. what Mozilla team they're in). Would your site benefit from this type of information if it were available in the new auth solution?
* Does your site accept other login methods beyond Persona currently (e.g. github, mozillians, google+) and if so which ones?
* Do you currently take advantage of the branding capabilities[2] of Persona which allow you to put your site's logo or site name in the Persona login popup? Do you have requirements for your replacement auth solution related to branding? A specific example around branding is the fact that the Firefox Accounts auth solution has "Firefox" branding associated with the login process which may or may not be acceptable to you for your site.


[1]: https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers
[2]: http://identity.mozilla.com/post/27122712140/new-feature-adding-your-websites-name-and-logo

Comment 3

[Wesley Dawson [:whd]]

> * Has an alternative authentication solution been selected for the site, if so what is the new planned auth solution?

No.

> * Is there a timetable and resources to complete the development of the change before November 30th?

Yes. This work is planned for Q3.

> * Would you like any help in coming up with an alternate auth solution? We have reference architectures for a handful of frameworks. If so, either schedule a Vidyo call with me or I will schedule one with you.

I think a combination of people from :kparlante, :lonnen and :travis's teams are going to work this out in Q3. We may solicit your input then.

> * How would you characterize your site's userbase? Do users that login currently consist only of people with Mozilla LDAP accounts? Do Mozilla contributors/community also currently log into the site? Does the general public log into the site?

LDAP users and some external partners. I believe there is a desire to allow NDA'd contributers access as well. The general public does not log into the site.

> * Since your currently using Persona for auth I'm assuming that your site doesn't have access to metadata about users stored in LDAP (e.g. first and last name) or access to LDAP group information of users (e.g. what Mozilla team they're in). Would your site benefit from this type of information if it were available in the new auth solution?

Yes.

> * Does your site accept other login methods beyond Persona currently (e.g. github, mozillians, google+) and if so which ones?

No.

> * Do you currently take advantage of the branding capabilities[2] of Persona which allow you to put your site's logo or site name in the Persona login popup? Do you have requirements for your replacement auth solution related to branding? A specific example around branding is the fact that the Firefox Accounts auth solution has "Firefox" branding associated with the login process which may or may not be acceptable to you for your site.

No, and no.

Comment 4

[Ryan Kelly [:rfkelly]]

Hi :whd, just to check in, what's the status of planning for this migration?  I'm doing to pass on all outstanding Persona reliers to see how things are shaping up as November 30th gets closer.

Comment 5

[Wesley Dawson [:whd]]

I'm doing this either later this week or next week. We're replacing apache+persona with nginx+googleauth, which I've gone over how to do with :relud.

Comment 6

[Wesley Dawson [:whd]]

The stage and prod heka and fxa aggregators have been switched to google auth, as well as metrics.s.m.c. This is mostly accomplished by https://github.com/mozilla-services/puppet-config/pull/2361, but I will add the metrics.s.m.c. bits tomorrow before closing this out.

Comment 7

[Wesley Dawson [:whd]]

I've added the remainder of the logic necessary. Notably :jrgm and I debugged some nasty XHR-related oauth session stuff for the heka dashboards resulting from multiple nginx workers using different session secrets, causing sessions to be invalidated nondeterministicly.