Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • lemonldap-ng lemonldap-ng
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 330
    • Issues 330
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 14
    • Merge requests 14
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LemonLDAP NG
  • lemonldap-nglemonldap-ng
  • Issues
  • #2083

Closed
Open
Created Feb 03, 2020 by Maxime Besson@maxbes🔧Maintainer

Offline sessions do not work with delegated auth providers (saml, oidc...), choice and combination

Concerned version

Version: 2.0.7

Summary

The current implementation of offline sessions (see #813 (closed)) calls getUser to refresh user attributes when the refresh token is exchanged for a new access token.

This is necessary because these sessions can be very long lived, and we might want them to "see" when an attribute is updated.

When using a delegated provider (SAML, OIDC, facebook...), getUser/setSessionInfo will not work outside of a a complete authentication flow. Which causes an error:

Logs

[debug] OpenID Refresh Token: 27f0e30f46e54f4c37bc439c23d49566e529615a853b099f9e83f143402e949b
[debug] Processing getUser
[debug] Returned error: 9 (PE_FIRSTACCESS)
[error] Could not resolve user: df8a8d4d-e26d-4d5f-a323-ea35e17f26ce
[warn] [anonymous] invalid_grant

Possible fixes

I can see several fixes:

  • Ignore getUser errors when refreshing the token

  • Avoid refreshing the user info entirely: we might need an "isRefreshable" method in each auth provider that tells LLNG if we can call UserInfo on this provider outside of an auth context. This could also be useful for cases like "Refresh My Rights" and password reset.

Edited Feb 28, 2020 by Maxime Besson
Assignee
Assign to
Time tracking