On 28/11/2015 13:13, Peter Bengtsson wrote:
> On Wed, Nov 25, 2015 at 5:52 PM, Ryan Kelly <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     On 26/11/2015 00:25, Peter Bengtsson wrote:
>     > On Tue, Nov 24, 2015 at 4:25 PM, Ryan Kelly <[email protected] 
> <mailto:[email protected]>
>     > <mailto:[email protected] <mailto:[email protected]>>> 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
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct

Reply via email to