On Tue, Nov 24, 2015 at 4:25 PM, Ryan Kelly <[email protected]> wrote:
> On 25/11/2015 05:43, Peter Bengtsson wrote: > > On Tue, Nov 24, 2015 at 1:40 PM, Christopher Karlof <[email protected] > > <mailto:[email protected]>> wrote: > > > > FxA is a consumer account system, and for Mozilla services which are > > available to the general public, it’s a viable option. > > > > The above demonstration would be most viable for services which are > > internal and require LDAP/Okta authentication. > > > > If there are services which need *both* types of authentication, we > > may not have a clean answer like we did with Persona, but we could > > just offer both. > > > > > > I want both. Nay, I *need* both types. > > Can you please say more about the specific use-case here? I can imagine > us directing many future queries to the archive of this thread. > > Air Mozilla: Staff email's that log in automatically have access to private events/videos. Non-staff emails need their accounts tied to a vouched Mozillian account. Future, we want non-staff and non-vouched-mozillians to be able to log in. Crash Stats: Staff who log in need to use their work email if they're going to be given PII access. Partners such as Adobe need to be able to sign in too. > > FxA plus a tool that informs when LDAP statuses change (in particular > > when someone ceases to have LDAP staff status) would suffice. > > You could do what Persona does, ask for the email up-front and direct > the login to whatever system is most appropriate - Okta for staff > addresses, FxA for everyone else. > > Pardon my ignorance but why is Okta [for staff] any better than FxA? > (And if we were going to need this a lot, we could make a small utility > lib/service to abstract it away). > > > Ryan > > > > On Tue, Nov 24, 2015 at 5:43 AM, Peter Bengtsson > > <[email protected] <mailto:[email protected]>> wrote: > > > > That's really cool and clearly works. > > However, non-staff would be confused when they see that Okta > > sign in. In fact, how do non-staff sign in at all? > > > > Either way, I think I would like to use FxA. Isn't that a > > project we're trying to promote in general in the company? > > > > On Mon, Nov 23, 2015 at 6:23 PM, Daniel Coates > > <[email protected] <mailto:[email protected]>> wrote: > > > > There's a demo of the current progress here: > > https://123done-dcoates.dev.lcip.org with code here: > > https://github.com/dannycoates/123done/tree/google-auth > > > > On Mon, Nov 23, 2015 at 1:59 PM, Ryan Kelly > > <[email protected] <mailto:[email protected]>> wrote: > > > On 24/11/2015 05:07, Sean McArthur wrote: > > >> +dev-fxacct > > >> > > >> We are working on figuring this out for the company. It's > > looking like > > >> the solution for sites that require employee accounts can > > use Google > > >> Sign In, and require it to use okta. > > > > > > Indeed, IIUC Danny has put together a working demo of this > > using > > > Google's OpenID Connect login flow, which bridges to Okta > > and thus auths > > > against LDAP for @mozilla.com <http://mozilla.com> > addresses. > > > > > > We'll see about putting together a little how-to for other > > folks to try > > > out, I hear it was pretty painless to set up. > > > > > > > > > Cheers, > > > > > > Ryan > > > > > > > > >> On Mon, Nov 23, 2015, 9:49 AM Peter Bengtsson > > <[email protected] <mailto:[email protected]> > > >> <mailto:[email protected] > > <mailto:[email protected]>>> wrote: > > >> > > >> For the record, we wouldn't interface with Workday at > > all. Only > > >> ldap.mozilla.org <http://ldap.mozilla.org> > > <http://ldap.mozilla.org>. > > >> (How ldap.mozilla.org <http://ldap.mozilla.org> > > <http://ldap.mozilla.org> gets populated is > > >> out of context). > > >> > > >> On Mon, Nov 23, 2015 at 12:18 PM, Schalk Neethling > > >> <[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] <mailto: > [email protected]>>> > > >> wrote: > > >> > > >> > As long as it does not do a 'if in workday' pass or > > else you shall not > > >> > pass :) > > >> > > > >> > Geo contractors are not in Workday. > > >> > > > >> > On Mon, Nov 23, 2015 at 6:47 PM, Peter Bengtsson > > >> <[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] <mailto: > [email protected]>>> > > >> > wrote: > > >> > > > >> >> Suppose you use Persona to auth people to your > > site. Given that > > >> someone > > >> >> manages to log in with a @mozilla.com > > <http://mozilla.com> <http://mozilla.com> (or > > >> foundation or mozilla-jp) > > >> >> they've > > >> >> proven they're active staff. > > >> >> If they leave the company, most likely their > > access to your site, > > >> under a > > >> >> staff email address, should cease. E.g. logging in > > to Air Mozilla > > >> to see > > >> >> staff live events. Persona took care of that as > > each new session got > > >> >> checked against the provider (e.g. mozilla.com > > <http://mozilla.com> <http://mozilla.com>). > > >> >> > > >> >> If we switch to FxA we lose this automatic check > > that Persona > > >> used to do. > > >> >> You OAuth sign in a user and set her cookie to > > last X weeks and > > >> she'll be > > >> >> signed in for X weeks. How do you kill that > > session cookie if she no > > >> >> longer > > >> >> has ability to check check email to her > > @mozilla.com <http://mozilla.com> > > >> <http://mozilla.com> address? > > >> >> > > >> >> Is there already an established solution for this? > > >> >> > > >> >> If not, I'd be up for writing a central solution > > for talking to our > > >> >> ldap.mozilla.org <http://ldap.mozilla.org> > > <http://ldap.mozilla.org> (which is a derivative > > >> of Workday). > > >> >> We can either stand up a service that your server > > can query or we can > > >> >> stand > > >> >> up a service that can webhook-post to you. > > >> >> > > >> >> What do you think? > > >> >> > > >> >> > > >> >> -- > > >> >> Peter Bengtsson > > >> >> Mozilla Web Engineering > > >> >> _______________________________________________ > > >> >> dev-webdev mailing list > > >> >> [email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>> > > >> >> https://lists.mozilla.org/listinfo/dev-webdev > > >> >> > > >> > > > >> > > > >> > > > >> > -- > > >> > Kind Regards, > > >> > Schalk Neethling > > >> > Senior Front-End Engineer > > >> > Mozilla ::-:: > > >> > > > >> > > >> > > >> > > >> -- > > >> Peter Bengtsson > > >> Mozilla Web Engineering > > >> _______________________________________________ > > >> dev-webdev mailing list > > >> [email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>> > > >> https://lists.mozilla.org/listinfo/dev-webdev > > >> > > >> > > >> > > >> _______________________________________________ > > >> Dev-fxacct mailing list > > >> [email protected] <mailto:[email protected]> > > >> https://mail.mozilla.org/listinfo/dev-fxacct > > >> > > > _______________________________________________ > > > Dev-fxacct mailing list > > > [email protected] <mailto:[email protected]> > > > https://mail.mozilla.org/listinfo/dev-fxacct > > > > > > > > > > -- > > Peter Bengtsson > > Mozilla Web Engineering > > > > _______________________________________________ > > Dev-fxacct mailing list > > [email protected] <mailto:[email protected]> > > https://mail.mozilla.org/listinfo/dev-fxacct > > > > > > > > > > > > -- > > Peter Bengtsson > > Mozilla Web Engineering > -- Peter Bengtsson Mozilla Web Engineering
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
