[Joplin Serve] Support SAML SLS/SLO

Features
1

Hey,

it would be great if we could support for SLO (Singe logout).
This would enable the user to logout all joplin clients instantly (for example when the user changes a password).

2

SAML is actually supported. I've recently documented it here:

LDAP too:

3

Yes and thats working (kinda I have the same issue as someone else mentioned here: Can't complete SAML login flow on Mac client APP · Issue #13640 · laurent22/joplin · GitHub )

My question is to add support for SAML SLO: Single Logout Explained | SAML SLO Guide

The use case is that when the user logs out from the IdP (eg. Keycloak/Authentik) he should be automatically logged out from all the services (Joplin Server in this case).
Currently Joplin waits for token invalidation and being unable to refresh it which can result in things like:

The user logs out using the IdP but still being logged in in Joplin which causes a security risk.

4

I've done some tests with SAML recently and I tried for example deleting a session in Keycloak and I could see login was required again in the client.

Or maybe it's because the required changes in Joplin Server for this haven't been published yet. But the process would be similar right - the logout process deletes the session, and all clients disconnect?

5

I'm creating a new release of Joplin Server so maybe you can give it a try. Also make sure you use the latest pre-release for the tests.

6

No still not working.
Just to confirm you have not configured any SLS Urls in Keycloak right?

My workflow (with authentik but still):

  1. log into Joplin using SAML
  2. Create sync code
  3. sync notes
  4. logout in authentik dashboard
  5. test if joplin syncs & joplin web browser still have a valid session
  6. both do both work despite being logged out in authentik. Revisiting authentik directly presents me with a login state.
  7. Expected: If I am logged out of authentik I am logged out of joplin.

A lot of people think that this would break currenty deployed instances but be aware that without directly entering a SLS Endpoint in Authentik/keycloak or whatever IdP you use will change nothing so this feature is by design opt-in.

Tested with:
Joplin Server: v3.5.1
Joplin: v3.5.9 Portable on windows

7

Perhaps a more valid use case:

If I disable the user he still has access to joplin as long as the token is valid inside joplin.

8

Ok I see, now I remember I was testing the actual login workflow. I didn't try to invalidate the session on Keycloak and check if the session on JS is invalidated too, but indeed I'd expect it's not. I guess there would have to be a background service or something that periodically check the SAML server to know if the JS session should be cleared.

We may implement this at some point or alternatively I'd probably accept a PR that adds the feature.

9

No SAML SLO/SLS is a workflow/extension of SAML.

JS would need to expose some kind of endpoint that can handle the response.
So the workflow would look something like this:

User logs out (IdP) → IdP sends request to Joplin Server → Joplin Server handles request → Joplin Server invalidates sessions etc.

So basically JS gets notified when something has to be done.

This is why the endpoint and SLO has to be manually configured on your IdP (Authentik, Keycloak, etc.) and if you do not want this you can just skip this step.

10

A typically request would look like this:

<samlp:LogoutRequest xmlns: samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://idp.example.com/logoutService" ID="_6d0a9a4dbd356e2447b25dfald52e796" IssueInstant="2022-08-26T09:16:39Z" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://dev.application.com/saml-sp</saml:Issuer>
<NameID xmlns="urn: oasis: names: tc: SAML:2.0: assertion"›user1@yourdomain.com</NameID>
<samlp:SessionIndex>_30f323d6-e259-4200-8dc5-4159d6f95fd6</samlp:SessionIndex>
</samlp:LogoutRequest>

So this is what Joplin would need to handle/receive

11

Yes that's fine, whether it's done via polling or a web hook, it's not currently supported and would need to be implemented

1 Like
12

Yes thats right.

Just wanted to note that we don’t have to develop something new we just need to implement this standard.

1 Like
13

I’m a newbie to SSO setup so it might be a me problem. But I spent days arguing/fighting with Claude and Gemini on how configure this. There were some pitfall what were not obvious but maybe to a seasoned person they are. I was using authentik for SSO. So put here to help the next newbie.

  • Must remove the Verification Certificate from the Joplin Provider (otherwise joplin-sp.xml will have AuthnRequestsSigned="true")
  • Create custom property mappings with simple attribute names (email and displayName), not URI-format names that are the default in authentik (that have this as the attribute “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” instead of just “email”)
  • Permissions on the XML files (joplin-idp.xml and joplin-sp.xml) the Joplin server app runs as uid 1001… so give read/execute permissions and or give everyone read access
  • summary of parameters to add to compose:
    • # SAML CONFIG
      • SAML_ENABLED=${SAML_ENABLED}
      • SAML_IDP_CONFIG_FILE=/saml/joplin-idp.xml
      • SAML_SP_CONFIG_FILE=/saml/joplin-sp.xml
      • DELETE_EXPIRED_SESSIONS_SCHEDULE= # Empty to disable auto-logout
  • If you continue to get errors… use Dozzle to inspect the Log for errors (which is highlights in red or search for ones related to SAML… then ask AI what it means if it’s not obvious… but sometime it will assume and lead you astray… so question when it doesn’t feel right or you might end up going in circles… keep checking the logs and ask what that means

Hope this saves you days/hours that I lost to trying to learn and figure this out.