On Tue, Nov 24, 2015 at 1:40 PM, Christopher Karlof <[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. FxA plus a tool that informs when LDAP statuses change (in particular when someone ceases to have LDAP staff status) would suffice. > -chris > > > > On Tue, Nov 24, 2015 at 5:43 AM, Peter Bengtsson <[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]> >> 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]> 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 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]>> wrote: >>> >> >>> >> For the record, we wouldn't interface with Workday at all. Only >>> >> ldap.mozilla.org <http://ldap.mozilla.org>. >>> >> (How 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]>> >>> >> 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]>> >>> >> > 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> (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>). >>> >> >> >>> >> >> 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> 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> (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]> >>> >> >> 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] >>> > >>> >> https://lists.mozilla.org/listinfo/dev-webdev >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Dev-fxacct mailing list >>> >> [email protected] >>> >> https://mail.mozilla.org/listinfo/dev-fxacct >>> >> >>> > _______________________________________________ >>> > Dev-fxacct mailing list >>> > [email protected] >>> > https://mail.mozilla.org/listinfo/dev-fxacct >>> >> >> >> >> -- >> Peter Bengtsson >> Mozilla Web Engineering >> >> _______________________________________________ >> Dev-fxacct mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/dev-fxacct >> >> > -- Peter Bengtsson Mozilla Web Engineering
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
