(Auth0 Lock) Disallow use of locks other than the "hosted lock" or our preferred lock

[hmitsch]

@tristanweir commented on Wed Feb 15 2017

Replaces https://github.com/mozilla-iam/auth0-deploy/issues/89

We could do this by failing to login and showing a warning with a link to the documentation.

Ex rule (do not use this as-is, it's more of a POC):

function (user, context, callback) {
  // This rule will refuse login to any lock that does not appear to be our hosted lock.
  // Bypass for xxxx
  if (context.clientID === "xxxx") {
     return callback(null, user, context);
  } else if (user.auth0_client && user.auth0_client.name === "lock-passwordless.js") {
     return callback(UnauthorizedError("Please use the hosted lock. See docs at https://wiki.mozilla.org/Security/Guidelines/OpenID_Connect#Session_handling and https://github.com/mozilla-iam/testrp.security.allizom.org/"));
  }
  callback(null, user, context);
}

The concept here is to set an attribute in the hosted lock that we can check for within a rule. The above rule uses an attribute the modal passwordless lock currently sets (which our hosted lock does not).

It's also important to note that we should only block new clients - as to not break clients that currently do not use the hosted lock yet but have planned to migrate.

Finally here's an example of user data and context information for a login via the modal passwordless lock:

{
  "date": "2016-12-22T19:37:54.638Z",
  "type": "s",
  "connection": "email",
  "connection_id": "con_xxxx",
  "client_id": "xxxx",
  "client_name": "air.mozilla.org",
  "ip": "xxxx",
  "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0",
  "user_id": "email|xxxx",
  "user_name": "xxxx",
  "strategy": "email",
  "strategy_type": "passwordless",
  "auth0_client": {
    "name": "lock-passwordless.js",
    "version": "2.2.3",
    "lib_version": "6.8.0"
  }
}

[gdestuynder]

this also requires moving airmo and TC to hosted lock

[gdestuynder]

we re-had this discussion today as well during tech alignment, output:

Security-wise: should use hosted / 1 url for password managers to associate with LDAP password Known RPs not using hosted that plan to switch: airmo, taskcluster Hosted lock ensure consistent ux/ui Can be “forbid” that via rules? Expectations: this is how other providers work We actualy had this also https://github.com/mozilla/iam-project-backlog/issues/40

[hmitsch]

Hi @gdestuynder,

thanks for the write-up from last week. ParSys can probably help moving AirMo to the hosted lock. We will look into that in the next couple of sprints.

On the #iam IRC channel there seems to be a longer conversation with Dustin. I think he is working on taskcluster. Does this mean that we also have a migration path in sight there?

Best regards, Henrik

[gdestuynder]

For taskcluster I think so but I do not know what his timeline is, @djmitche

[djmitche]

I believe the hosted lock still does not support passwordless login as the only option, which is what we are using.

The next step for TC is to act as an auth0 API, but that is awaiting the new profile (so, probably to be worked on during Q3).

[gdestuynder]

i vote to whitelist tc/airmo until its fixed, and go ahead with the rule as not having it causes expectation issues which may be more difficult to solve if modal is used elsewhere (see also https://github.com/mozilla-iam/auth0-deploy/issues/117)

[gdestuynder]

this is blocked on airmo not using the hosted lock notes:

• change in airmo might be easy to make
• EUS is on point for the airmo update/replacement, likely in september 2017

[djmitche]

TC is no longer blocking this.

[gdestuynder]

airmo is the last piece blocking this