Re: Fwd: Auth0 - are you still an employee?


(kang) #1

+iam@mozilla-community.org

Thanks Peter!

Note, just to clarify for readers:

the use case for this is to de-provision users outside of the interactive user logins (i.e. when you need to check if a user exists and is valid but the user is not actively browsing your web site).

Some answers in no particular order:

  • [1] The vendor agnostic alternative that we were thinking about so far is to expose a CIS API, but this is not on the todo list for now (so I added an issue at least), though PRs are welcome of course :wink: Would be quite nice though!

  • Auth0 hooks: there isn’t the hook we want out of the box yet, though we could draft a rule that triggers a webhook as well. I’d be surprised if Auth0 does not eventually support this out of the box though as there are already similar hooks being added.

  • [2] We do have a backlog item for self-servicing client_id+secret requests (which I’d love to have already!), but I do not think we will have this for management API requests as this exposes more data, attack surface, has a strong vendor lock-in, we cannot verify that your session checks work remotely, etc. This is for cases where it makes sense basically, which so far there are 3 of (out of about ±80 clients). In order words these are actually exceptions and handled as such which I believe is fine. Note that if we ever get to work on [1] you would get the access by default and would not need request, which would be the best of both worlds

Guillaume

[1] https://github.com/mozilla-iam/iam-project-backlog/issues/174

[2] https://github.com/mozilla-iam/iam-project-backlog/issues/111


(Yousef Alam) #2

Discourse didn’t post the fwded email so here:

On Fri, Jul 21, 2017 at 7:21 AM, Julien Vehent ulfr@mozilla.com wrote:
cc secops for visibility

Great stuff Peter!!!

On Fri 21.Jul’17 at 10:03:00 -0400, Peter Bengtsson wrote:

(Apparently sending this to iam-dev@m.c was a bad idea. It bounced)

---------- Forwarded message ----------
From: Peter Bengtsson pbengtsson@mozilla.com
Date: Fri, Jul 21, 2017 at 10:01 AM
Subject: Auth0 - are you still an employee?
To: Tasos Katsoulas akatsoulas@mozilla.com, John Giannelos <
nemo@mozilla.com>, William Kahn-Greene willkg@mozilla.com, Chris
Lonnen <
lonnen@mozilla.com>, IAM Dev iam-dev@mozilla.com, Benson Wong <
bwong@mozilla.com>

Today I landed https://github.com/mozilla-services/tecken/pull/245
It’s a thing in Django that periodically checks, using the Auth0
Management
API, if you’re blocked. (“blocked” == exists but marked as disabled.
Something that happens when a user leaves employment status in Workday).
Reminder; Tecken uses mozilla-django-oidc.

The implementation is relatively trivial but it sets an important
precedent.
After authenticating I can set a really long cookie age so as to not
bother
users to have to sign in again. Apart from the throttle (I use caching to
not make this network-bound check every single request) this knocks out
the
user as soon as possible when they leave employment. Best of both worlds!

Also, this does NOT depend on the client being an actual browser that
will
follow redirects. This means that custom API tokens my clients use stop
working too since the API tokens just ties into the regular Django user
auth framework.

  • Who else have been involved in these chats who might like a forward?
  • I still have to pester by bug or by The Hub to have the auth0
    management
    api feature enabled for stage and prod :frowning:
  • If there was a webhook in Auth0 that could HTTP PUT/POST me when a
    user’s
    status changes then I could additionally benefit from that to make that
    look-up right here right now. It doesn’t have to be trusted but it’d be
    nice to be able to checksum using my Client ID who it came from.
  • I opted for only bothering with users found in Auth0.
  • Now, if only there was a way to do this that was vendor agnostic.


Peter Bengtsson
Mozilla Engineering Operations


Peter Bengtsson
Mozilla Engineering Operations