Access tokens are not invalidated when credentials are invalidated via an external auth provider

[richvdh]

If synapse is configured to interface with an external auth provider (such as LDAP), there is no mechanism for that external system to feed back to synapse if a user's credentials have been locked/revoked/etc. Synapse's access_tokens stay valid forever.

A related question: if a user's password is changed in the external system, should we require all matrix clients to log in again, as we would with a local password change? If so, how should this be implemented?

[BloodyIron]

Any idea when this might get looked into? :)

[BloodyIron]

This is actually a blocker for me. Is there any possibility of a milestone for this one? :(

[neilisfragile]

Hi @BloodyIron fixing this properly is going to need some thought and is probably related to matrix-org/matrix-spec-proposals#1467

As of the right now, the main focus of the team is to complete our r0 release of the S2S API, you can track progress here https://github.com/orgs/matrix-org/projects/2 though is still a lot outstanding.

This means that I can't in good faith give you a time frame for addressing this issue. Things that would help bump it up the to do list would be commercial sponsorship of the work, or lots of people also needing it fixed.

[BloodyIron]

Hi @neilisfragile well, the ticket you link to is kinda similar, but I wouldn't fully agree about it being completely related.

As for S2S API, I'm not familiar with what that is and I can't really discern that from the trelo board you linked me to.

As for this particular topic, I've been thinking about it more. My understanding is that those behind riot.im and matrix.org rolled out the modular.im service, with the intent of it being a B2B kind of service. If the intent is indeed to provide the service to businesses, I guarantee you the majority of them are going to ask how it will integrate with their existing Authentication system (probably will be Active Directory, failing that LDAP).

If those people are unable to lock users out, or force people to log back in with a password change, that will be a hard block for setting that up. Think about it, if a staff member is fired, and you can't prevent them from being able to use riot.im on their phone by locking them out, that's a big deal.

I can understand that other things are likely going to be hammered out before this. But I really do think the perception of this issue is being undervalued in terms of a security and business perspective. I may be asking for it now, but I guarantee you there will be plenty of clients that will NEED this before they can have confidence in riot.im/matrix.org.

So, not sure if you're involved with flagging tickets, or if that's someone else, but I really do think this warrants a p1.

[neilisfragile]

I think we are agreeing with each other here

As you suggest there is commercial value in the feature and Modular is an obvious use case hence. "Things that would help bump it up the to do list would be commercial sponsorship of the work ..."

The feature is obviously valuable, but open spec work to back r0 takes precedence.

If I give it P1 it means we are working on it pretty much right now, it goes on our immediate to do at the expense of something else, this is why it is P2.

[BloodyIron]

@neilisfragile alright, well do you anticipate this could be explored in the next say 1-2ish months? I'm not exactly 100% on how the priorities (numbering) work for this team. :)

But I am glad that you see the value I'm trying to express! :D

[neilisfragile]

Given the volume of r0 work, doing this in next 1-2 months is not realistic. Really, it will take commercial sponsorship to get this done anytime soon.

[BloodyIron]

Any word on this? I'm quite certain entities such as the Government of France will likely care about something like this. What's your take @ara4n ?

[madmatt]

A related question: if a user's password is changed in the external system, should we require all matrix clients to log in again, as we would with a local password change? If so, how should this be implemented?

As far as I know this isn't possible. LDAP works by binding to an LDAP controller (either binding as an admin and then authenticating with user-supplied details, or binding directly with the user's credentials). So whenever you get the user's raw username/password, you can check that they still work, but unless you keep those details decryptable in a server-side session or similar, you can't re-check that their login is still valid and that their password hasn't changed in the meantime.

Either way, if you're using LDAP or SAML to authenticate, you generally end up creating a Synapse-specific session, and as long as that session remains valid a user can remain logged in. If the user is removed from the source in the meantime, you won't see that until the user next attempts to login.

Maybe I'm just misunderstand what you're asking for though, if so please let me know. I'm not familiar at all with Matrix or Synapse, so might be totally missing the point - sorry if that's the case!

[BloodyIron]

@madmatt IMO binding with a trusted account is the way to go, as it can check the account status against the domain (AD/LDAP) and the domain can return "locked/disabled/good" or whatever, without having to "pass the hash" for the user, in the account status check.

I'm not sure if this check should reside in the identity server or matrix itself, however what I see is that at some point matrix needs to be aware of these account states, so that it can enforce an appropriate action. (tell user account is locked, or disabled, or whatever)

If we look at the recent token invalidation action that matrix.org and riot.im took, that's a pretty dang good example of a way this can be functionally achieved, except more finely tuned to the per-case basis (UX adjustment based on state).

This is commonplace for any system working against LDAP/AD, as this is a required function in corporate/secured space. Otherwise you couldn't prevent users who are already logged in from doing nasty stuff (say when you fire them).

Alternatively this could involve kerberos, but not 100% sure if that's required or not, as I don't believe all LDAP ecosystems use kerberos, while AD does.