Skip to content

Feature Request: 3rd party authentication server method #2019

Closed
Closed
Feature Request: 3rd party authentication server method#2019
Assignees
xet7
Labels
Feature:User-accounts:KeycloakFeature:User-accounts:Siteminder
Milestone
Auth

Description

@NerikBnp
NerikBnp
opened on Nov 23, 2018

In the context of a wekan instance hosted on a private protected network we need to set up a SSO integration with an Authentication server implementing security by filtering http requests.

When resquesting access to wekan instance 3rd party authentication server captures the requests to authenticate user and checks permissioning. If authentication is successful 3rd party authentication server allows routing to wekan server as well as injects HTPP headers with authentication context. So from wekan perspective a request arriving on wekan should be considered auhtorized and needs to start session for user provided in HTTP headers.

What needs to be implemented:

  1. Enable 3rd party authentication server method on wekan for all users
  2. All users authentication method is forced to 3rd party authentication server
  3. Admin panel:
    i. Button/parameter to switch wekan to 3rd party authentication server mode
    ii. Admin form to fill map between wekan user information model and HTTP headers tag names
    a. UserName
    b. Fullname (allow concatenation of first name + last name tags)
    c. Email adress
  4. On first user connection with 3rd party authentication server mode enabled if user is not already present in database create a user using http headers information as defined in the mapping set in admin panel
  5. if user exists in database retrieve the http header tag mapped to UserName to start user session. This should not impact deep links to boards or card
  6. Inactivate change password in profile option menu if 3rd party authentication server mode is enabled
  7. the settings around 3rd party authentication server should be preserved when upgrading wekan.

Activity

  1. NerikBnp commented on Nov 23, 2018

    @NerikBnp
    NerikBnp
    on Nov 23, 2018
    Author

    Posted a bounty 500USD on this feature request: Bounty here

  2. xet7 commented on Nov 23, 2018

    @xet7
    xet7
    on Nov 23, 2018
    Member

    @NerikBnp

    Please add examples of 3rd party authentication server software.

    Wekan already has LDAP.

    It's also possible to add Google login proxybouncer in front Wekan login.

    CAS and OIDC partially work already.

    Later there will probably be also RocketChat, Google and Auth0 login.

    SAML is in Sandstorm Wekan, but not on Standalone Wekan yet.

    Friend login will be added sometime.

    Do you mean some of these, or something else?

  3. NerikBnp commented on Nov 23, 2018

    @NerikBnp
    NerikBnp
    on Nov 23, 2018
    Author

    Hi @xet7

    we’ve actually tried and set up all the authentication methods offered but none meet our security requitements and cloud access and usage restrictions.

    the 3rd party software in use is SSO siteminder

    we have tried:
    PASSWORD & LDAP : both still have the weaknesss of possible impersonation of someone else if you get the user password
    SAML : we’ve set up a sandstorm sso instance but faced issues with set up due to cloud restrictions in place as well as user experience being much less nice than wekan standalone
    CAS : is not a standard we can use
    CLOUD AUTH: all authentication that rely on web/cloud accounts (google, friend... ) are not allowed.

    we’ve tried our best with the already provided solutions hence this feature request.

  4. xet7 commented on Nov 23, 2018

    @xet7
    xet7
    on Nov 23, 2018
    Member

    Oh OK, you mean secure login without using passwords.

    Would you prefer adding SSO to Wekan with:

    a) siteminder

    b) SQRL. SQRL is secure single factor, and does not use any passwords.

  5. yuriy-yarosh commented on Nov 25, 2018

    @yuriy-yarosh
    yuriy-yarosh
    on Nov 25, 2018

    @NerikBnp

    1. 3rd party authentication server mode

    As long as this authentication server can comply to standartized auth API shouldn't be a big deal.

    1. ...user information model and HTTP headers tag names ... as defined in the mapping set

    I don't think that any kind of mapping set is needed for as long as 3rd party server comply to the API contract.

    This feature request looks a bit crude, whole HTTP headers mapping set thingy is a bit frustrating.
    Just want to clarify few things because you might waste a lot of time and money for this...

    BountySource had proven to be very unreliable as a problem-solver.

  6. NerikBnp commented on Nov 26, 2018

    @NerikBnp
    NerikBnp
    on Nov 26, 2018
    Author

    Thank you both for your feedbacks.

    Thing is that in our situation we need to navigate in a very constrained environnement and most of those are not my choice nor within reach to change.

    @xet7 we would only be able to use a) siteminder

    @yuriy-yarosh see my comments:

    3rd party authentication server mode
    As long as this authentication server can comply to standardized auth API shouldn't be a big deal.

    Unfortunately 3rd party authentication is not made thru standard auth API. As far as the endpoint (wekan here) is concerned Authentication happens upstream and endpoint doesn't receive unauthenticated requests. The request arrives at wekan endpoint = user is authenticated. You just need to start the user context.

    ...user information model and HTTP headers tag names ... as defined in the mapping set
    I don't think that any kind of mapping set is needed for as long as 3rd party server comply to the API contract.

    The mapping is in place as there are specific custom (to our organization) headers tags set but would rather not have them hardcoded.

  7. xet7
    added
    Feature:User-accounts:Siteminder
    on Dec 3, 2018
  8. xet7
    modified the milestones: 2019-02-28 Add/Remove/Bugs, 2019-03-31 Sandstorm on Jan 11, 2019
  9. xet7
    modified the milestones: 2019-05-31 Sandstorm, 2019-03-31 Auth on Feb 28, 2019
  10. xet7
    self-assigned this
    on Feb 28, 2019

  11. xet7 commented on Feb 28, 2019

    @xet7
    xet7
    on Feb 28, 2019
    Member

    I'm working on this. I will add comment to this issue when there is some progress.

  12. NerikBnp commented on Feb 28, 2019

    @NerikBnp
    NerikBnp
    on Feb 28, 2019
    Author

    hi @xet7 that’s great news. do not hesitate to reach out should you have any queries :)

  13. 48 remaining items

  14. xet7 commented on Jun 6, 2019

    @xet7
    xet7
    on Jun 6, 2019
    Member

    Hi,
    I received email where was some confusion about how I was planning to implement this. To clear the confusion, here are my detailed plans.

    Implementing this feature is still in progress. It is not ready yet. I plan to have this feature done sometime at 2019-06 or 2019-07.

    General Description

    This will be general header login implementation. Any webserver (Caddy/Nginx/Apache/Siteminder/etc) that provides user details in HTTP headers, can this way make Wekan autologin as that user, and also automatically create that user to Wekan when it does not exist yet.

    With header login, there is no need to have any other additional login, like LDAP/OAuth2/etc.

    How to provide headers to Wekan

    NOTE: I think HEADER_LOGIN_ID will not be used for anything. I guess it could maybe be checked that does it exists, or does it have some value. But I don't know is this really necessary at all. Maybe I could just not include it at all to Wekan?

    Docker example. Syntax: export settingname=headername.

    export HEADER_LOGIN_ID=HEADERUID
export HEADER_LOGIN_FIRSTNAME=HEADERFIRSTNAME
export HEADER_LOGIN_LASTNAME=HEADERLASTNAME
export HEADER_LOGIN_EMAIL=HEADEREMAILADDRESS

    Siteminder example. Header names could be different.

    export HEADER_LOGIN_ID=BNPPUID
export HEADER_LOGIN_FIRSTNAME=BNPPFIRSTNAME
export HEADER_LOGIN_LASTNAME=BNPPLASTNAME
export HEADER_LOGIN_EMAIL=BNPPEMAILADDRESS

    Login will work this way:

    1. Wekan checks does HEADER_LOGIN_EMAIL setting have some text, that has name of header to check, for example is there header name HEADEREMAILADDRESS or BNPPEMAILADDRESS or some other header name.
    2. Wekan checks does that header name have some value. For example, there could be HEADEREMAILADDRESS=joe@example.com or BNPPEMAILADDRESS=joe@example.com
    3. Wekan checks is there headers for firstname and lastname. If there is, Wekan combines it with space between, firstname + " " + lastname, to get fullname. This is because Wekan currently only stores fullname, and not firstname and lastname.
    4. If there is not existing user with that email address, Wekan creates new user with those details.
    5. Wekan autologins user.

    Possible addtitional features sometime later

    Headers also for these:

    • fullname
    • avatar image URL

    If someone has some additional headers that they really use in some other login provider, please add info about it as comment to this issue.

  15. xet7 commented on Jun 6, 2019

    @xet7
    xet7
    on Jun 6, 2019
    Member

    Would someone need to have this check, to limit allowed email addresses to specific domain?

    export HEADER_LOGIN_DOMAIN=example.com

  16. lnvr commented on Jun 15, 2019

    @lnvr
    lnvr
    on Jun 15, 2019 via email

  17. xet7 commented on Aug 24, 2019

    @xet7
    xet7
    on Aug 24, 2019
    Member

    @justinr1234 will start soon to try to code this feature. If he gets it working, he will get bounty.

    I currently have other work in progress.

  18. xet7 commented on Aug 25, 2019

    @xet7
    xet7
    on Aug 25, 2019
    Member

    Actually, I will do this myself anyway.

  19. FieldofClay commented on Mar 25, 2020

    @FieldofClay
    FieldofClay
    on Mar 25, 2020

    Based on the commits linked to this issue, it got somewhat documented but never implemented. Is this still on the cards?

  20. xet7 commented on Mar 25, 2020

    @xet7
    xet7
    on Mar 25, 2020
    Member

    @FieldofClay

    Yes, this is still on the todo list at Roadmap. It will be implemented once I figure out how in practice it's possible to do.

  21. xet7
    closed this as completedon Jun 17, 2020
  22. xet7
    reopened this on Jun 18, 2020
  23. xet7
    closed this as completedon Jun 18, 2020
  24. xet7
    reopened this on Jul 15, 2020
  25. xet7
    added
    Feature:User-accounts:Keycloak
    on Dec 3, 2024
  26. xet7
    closed this as completedin d9f1ecbon May 27, 2026
  27. xet7
    added a commit that references this issue on May 27, 2026

    Add Header Login. Part 2.

    45c4afd
  28. adrianohf
    added a commit that references this issue on May 31, 2026

    Add Header Login.

    d9f1ecb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Feature:User-accounts:KeycloakFeature:User-accounts:Siteminder

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions