FxAuth and LDAP and mozilla staff

[Peter Bengtsson]

Suppose you use Persona to auth people to your site. Given that someone
manages to log in with a @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).

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 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 (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

[Schalk Neethling]

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 <pbeng...@mozilla.com>
wrote:

> _______________________________________________
> dev-webdev mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webdev
>



--
Kind Regards,
Schalk Neethling
Senior Front-End Engineer
Mozilla ::-::

[Peter Bengtsson]

For the record, we wouldn't interface with Workday at all. Only
ldap.mozilla.org.
(How ldap.mozilla.org gets populated is out of context).

On Mon, Nov 23, 2015 at 12:18 PM, Schalk Neethling <sneet...@mozilla.com>
wrote:

[jop...@gmail.com]

If you goal is to authenticate employees then why not use mozilla.okta.com?

You get the same flow across the org, same password and user database, and
you can query LDAP group membership as part of the flow.
I got it working in node pretty easy, there is official python examples too.


Regarding FxA I got the impression that it was a personal account for your
settings. So maybe people don't want to use an @mozilla.com account.
(with persona it's a feature that you can be logged into multiple accounts)

[Sean McArthur]

+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.

On Mon, Nov 23, 2015, 9:49 AM Peter Bengtsson <pbeng...@mozilla.com>
wrote:

[Peter Bengtsson]

On 2 of the 3 sites I work on, anybody can sign in. But when you logged in
with a @mozilla.com address balloons come down from the ceiling (amongst
other things).

Also, mozilla.okta.com might have cool features but whenever I log in to
any employee service using okta it feels like a 5 second
redirection-spinaround penalty. A more direct and simple OAuth pattern is
usually much much faster.

> _______________________________________________
> dev-webdev mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webdev
>

[Ryan Kelly]

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 <pbeng...@mozilla.com
> <mailto:pbeng...@mozilla.com>> 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

> <sneet...@mozilla.com <mailto:sneet...@mozilla.com>>

> 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

> <pbeng...@mozilla.com <mailto:pbeng...@mozilla.com>>

> > 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
> >> dev-w...@lists.mozilla.org <mailto:dev-w...@lists.mozilla.org>

> >> 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
> dev-w...@lists.mozilla.org <mailto:dev-w...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-webdev
>
>
>
> _______________________________________________
> Dev-fxacct mailing list
> Dev-f...@mozilla.org
> https://mail.mozilla.org/listinfo/dev-fxacct
>

[Daniel Coates]

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

[Peter Bengtsson]

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?

[Benjamin Smedberg]

On 11/24/2015 8:43 AM, Peter Bengtsson 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?

As far as I know, Firefox accounts aren't meant to be a general-purpose
SSO system and are tied to Firefox product plans. I don't think we
should necessarily try to force accounts for things that aren't part of
the Firefox product strategy if it's not already an obvious fit.

--BDS

[Christopher Karlof]

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.

-chris



On Tue, Nov 24, 2015 at 5:43 AM, Peter Bengtsson <pbeng...@mozilla.com>

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?
>

[Peter Bengtsson]

On Tue, Nov 24, 2015 at 1:40 PM, Christopher Karlof <cka...@mozilla.com>
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.

[Ryan Kelly]

On 25/11/2015 05:43, Peter Bengtsson wrote:
> On Tue, Nov 24, 2015 at 1:40 PM, Christopher Karlof <cka...@mozilla.com
> <mailto:cka...@mozilla.com>> 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.

> 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.

(And if we were going to need this a lot, we could make a small utility
lib/service to abstract it away).


Ryan

> > 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
> <pbeng...@mozilla.com <mailto:pbeng...@mozilla.com>

> >> <mailto:pbeng...@mozilla.com

> <mailto:pbeng...@mozilla.com>>> 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
> >> <sneet...@mozilla.com
> <mailto:sneet...@mozilla.com>

> <mailto:sneet...@mozilla.com <mailto:sneet...@mozilla.com>>>

> >> 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
> >> <pbeng...@mozilla.com
> <mailto:pbeng...@mozilla.com>

> <mailto:pbeng...@mozilla.com <mailto:pbeng...@mozilla.com>>>

> >> > 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>).

> <mailto:dev-w...@lists.mozilla.org

> <mailto:dev-w...@lists.mozilla.org>>
> >> >> 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
> >> dev-w...@lists.mozilla.org
> <mailto:dev-w...@lists.mozilla.org>

> <mailto:dev-w...@lists.mozilla.org

> <mailto:dev-w...@lists.mozilla.org>>
> >> https://lists.mozilla.org/listinfo/dev-webdev
> >>
> >>
> >>
> >> _______________________________________________
> >> Dev-fxacct mailing list

> >> Dev-f...@mozilla.org <mailto:Dev-f...@mozilla.org>

> >> https://mail.mozilla.org/listinfo/dev-fxacct
> >>
> > _______________________________________________
> > Dev-fxacct mailing list

> > Dev-f...@mozilla.org <mailto:Dev-f...@mozilla.org>

> > https://mail.mozilla.org/listinfo/dev-fxacct
>
>
>
>
> --
> Peter Bengtsson
> Mozilla Web Engineering
>
> _______________________________________________
> Dev-fxacct mailing list

> Dev-f...@mozilla.org <mailto:Dev-f...@mozilla.org>

[Peter Bengtsson]

On Tue, Nov 24, 2015 at 4:25 PM, Ryan Kelly <rfk...@mozilla.com> wrote:

> On 25/11/2015 05:43, Peter Bengtsson wrote:
> > On Tue, Nov 24, 2015 at 1:40 PM, Christopher Karlof <cka...@mozilla.com
> > <mailto:cka...@mozilla.com>> 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?

[Ryan Kelly]

On 26/11/2015 00:25, Peter Bengtsson wrote:
> On Tue, Nov 24, 2015 at 4:25 PM, Ryan Kelly <rfk...@mozilla.com
> <mailto:rfk...@mozilla.com>> wrote:
> > 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?

Because it integrates with LDAP. If I create an FxA using my
@mozilla.com address, I retain access to that account even after I leave
the company (the same as for any other email address that I had
subsequently lost access to).


Cheers,

Ryan

[Peter Bengtsson]

> So, is the cookie only lasting something like 24h? Or does it ping
okta.com on every new session?

The effect you speak of can be achieved with a sync via some central tool
that checks in with LDAP periodically. Which was the original issue of this
thread. A tool I'm interested in developing if there isn't already one
available.




> Cheers,
>
> Ryan

[Ryan Kelly]

On 28/11/2015 13:13, Peter Bengtsson wrote:
> On Wed, Nov 25, 2015 at 5:52 PM, Ryan Kelly <rfk...@mozilla.com
> <mailto:rfk...@mozilla.com>> wrote:
>
> On 26/11/2015 00:25, Peter Bengtsson wrote:
> > On Tue, Nov 24, 2015 at 4:25 PM, Ryan Kelly <rfk...@mozilla.com <mailto:rfk...@mozilla.com>
> > <mailto:rfk...@mozilla.com <mailto:rfk...@mozilla.com>>> wrote:
> > > 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?
>
> Because it integrates with LDAP. If I create an FxA using my

> @mozilla.com <http://mozilla.com> address, I retain access to that

> account even after I leave
> the company (the same as for any other email address that I had
> subsequently lost access to).
>
> So, is the cookie only lasting something like 24h? Or does it ping

> okta.com <http://okta.com> on every new session?

Aha, sorry, I had missed that you were talking specifically about the
extra session-management goodies that you get out of persona's
id.watch() API. Neither FxA nor Google's OIDC bridge to Okta currently
provide an equivalent feature.

The Google/Okta flow will revoke you ability to create *new* login
sessions when your LDAP is deactivated; Firefox Accounts will not.

> The effect you speak of can be achieved with a sync via some central
> tool that checks in with LDAP periodically. Which was the original issue
> of this thread. A tool I'm interested in developing if there isn't
> already one available.

Sure, I can see this being helpful for managing application-level
session state in the absence of persona's watch() API.

You may be able to get a similar effect by using short-lived session
cookies for staff accounts, and regularly bouncing them through Google's
"no prompt" login flow [1] to silently check whether the account is
still valid. Less efficient than a webhook-post style system, but also
less infra to write and maintain on the Mozilla side.

IIUC this is similar to what Persona would do behind the scenes. But we
haven't tried it out in practice with the Google/Okta bridge.


Cheers,

Ryan


[1] https://developers.google.com/identity/protocols/OpenIDConnect#prompt