Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: 3rd party authentication server method #2019

Open
NerikBnp opened this issue Nov 23, 2018 · 55 comments

Comments

Projects
None yet
5 participants
@NerikBnp
Copy link

commented 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.
@NerikBnp

This comment has been minimized.

Copy link
Author

commented Nov 23, 2018

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

@xet7

This comment has been minimized.

Copy link
Member

commented Nov 23, 2018

@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?

@NerikBnp

This comment has been minimized.

Copy link
Author

commented Nov 23, 2018

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.

@xet7

This comment has been minimized.

Copy link
Member

commented Nov 23, 2018

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.

@yuriy-yarosh

This comment has been minimized.

Copy link

commented 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.

@NerikBnp

This comment has been minimized.

Copy link
Author

commented Nov 26, 2018

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.

@xet7 xet7 added this to In Progress: By RL in Wekan Roadmap Jan 11, 2019

@xet7 xet7 moved this from In Progress: By RL to In progress: by xet7, all paid and not paid Open Source Wekan work and all unrelated work. Order: from top to bottom of cards. in Wekan Roadmap Feb 28, 2019

@xet7 xet7 self-assigned this Feb 28, 2019

@xet7

This comment has been minimized.

Copy link
Member

commented Feb 28, 2019

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

@NerikBnp

This comment has been minimized.

Copy link
Author

commented Feb 28, 2019

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

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 1, 2019

@NerikBnp

  1. About Sandstorm:

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

When you tried Sandstorm, do you mean with user experience that there is only only one board per grain? Yesterday I added multiple boards per grain, Admin Panel etc more features of Standalone Wekan to Sandstorm Wekan #2208 but not all those features work yet. Do these make Sandstorm more usable, or is Standalone Wekan still better for you? Are your cloud restrictions too strict to have Sandstorm well installed?

  1. About Standalone Wekan and Siteminder:
  • Does Siteminder support OIDC OAuth2 login? Wekan supports 3rd party OIDC authentication servers like Keycloak that is Open Source, Keycloak settings are at Wiki. You did test Sandstorm with SAML, but Wekan does not have SAML in Standalone Wekan version yet. OIDC login experience is that OIDC button is clicked (or in future, redirected directly to auth login page) and then after logging to 3rd party auth user is redirected back to Wekan.
  • For HTTP header, would it be enough that to Admin Panel / People I would add new column that would have editable field for required HTTP header for that user?
@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@NerikBnp

Would you have time to answer my questions in above comment?

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@NerikBnp

Anyway, I presume I'll start by adding column for HTTP header for each user to Standalone Wekan Admin Panel, and then trying to make Wekan check for that header.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@NerikBnp

I will create trial account to siteminder so that I could try to do some testing. Although, I don't know yet what kind of trial account to create, I try to figure it out. It would be helpful if you could send me email to x@xet7.org if you could create some test account for me to siteminder, so I could test this.

@NerikBnp

This comment has been minimized.

Copy link
Author

commented Mar 7, 2019

Hi @xet7
about sandstorm the setup and grains are too much overhead for using only wekan.
whilste user experience in wekan is really great, it felt more complex in sandstorm. also to note that we are not interested in any of the other features currently proposed in sandstorm.

we have tried Oidc but could not make it work

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@NerikBnp

Can you try again with some example Oidc settings like these, that do work already?

@NerikBnp

This comment has been minimized.

Copy link
Author

commented Mar 7, 2019

re siteminder account not sure going for test account would be posible i’ll check and revert back. it might require to be stubbed. I may ask to get some data response samples upon successful login to test.

on the http headers actually some header should map existing user data: username, first name last name.. to allow creation of user on 1st connection and then identify context (who is actually logged in)

@NerikBnp

This comment has been minimized.

Copy link
Author

commented Mar 7, 2019

@xet7 i’ll ask the person who ran the test on oidc to join the discussion ;)

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@NerikBnp

When mapping fields with Oidc to wekan, those fields like username etc will be available for Wekan code so Wekan could check for some kind of header that is combined from those, but I would need more details about how that header is made like what it looks like, how user info is combined to it, etc, so I could check correct type of header with code.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

For example, Wekan login page could have some check, that if some general part of header exists, then also check other parts of header does it have username or some other identifying info, search does that user exist in database, and if yet, then login user.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

In that case, there would only need to be settings input box and save button (or environment varible setting) for generic part of header that is always the same, and other data would be get directly from Oidc mappings.

@NerikBnp

This comment has been minimized.

Copy link
Author

commented Mar 7, 2019

yes that would be the idea.

i will share some headers data sample that would be the easiest way for you to progress with this.

@NerikBnp

This comment has been minimized.

Copy link
Author

commented Mar 7, 2019

one question to be crystal clear re Oidc mappings could the mapping mecanism be used even if we’re not in an oidc auth mecanism but in our siteminder set up?

@lnvr

This comment has been minimized.

Copy link

commented Mar 7, 2019

Hello xet7,

I'm working with NerikBnp,

For the moment, our architecture for Wekan is :
A load balancer, then 2 Apache reverse proxy, then a load balancer, then the applicative servers of Wekan.

The Apaches in reverse proxy have a "Siteminder WebAgent" installed, these agents communicates with the SSO Policy server.

It's working well, when a user is in the right SSO LDAP group, the user is allowed to access Wekan.

The problem is the Wekan is not able to login the users with the headers provided by SiteMinder :
BNPPUID
BNPPFIRSTNAME
BNPPLASTNAME
BNPPEMAILADDRESS

So we would like to bypass the sign-in page and we would like the users to be logged in with the headers provided by Siteminder.

For the OAUTH2 / OIDC settings i've used the values provided by the SSO team, but it's not working with Siteminder, it's Vordel in that case.

Thank you

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@lnvr nvr

What errors you get in Oidc login? When you add these settings and look error logs?

Snap

sudo snap set wekan debug='true'

Then login and check logs

sudo snap logs wekan.wekan

More detailed logs:

sudo systemctl status snap.wekan.wekan

Docker

docker-compose.yml from https://github.com/wekan/wekan

export DEBUG=true

And then login and look at logs:

docker logs wekan-db
@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@lnvr

Nevermind my above question about OIDC, it's good LDAP login works. So then it's just that I try to make LDAP login with those headers.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

so my guess is “all you might have to do” is a global variable to set auth to siteminder.
and if that then consume headers (that could be session variable too) either to start user session or to create a user on 1st connection.

Ok, then I think it would be like these:

Snap

sudo snap set wekan siteminder-enabled='true'

Docker

export SITEMINDER_ENABLED=true
@xet7

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@lnvr

Actually, now that I think of it, there is more general use case, partially related to #2195, so this would not need to be siteminder-specific. There would be following settings. Then, if someone has Apache or other webserver providing headers, Wekan would automatically login.

But does headers not include password? I would think that usually login to LDAP is with password.

Snap

sudo snap set wekan header-login-id='BNPPUID'
sudo snap set wekan header-login-firstname='BNPPFIRSTNAME'
sudo snap set wekan header-login-lastname='BNPPLASTNAME'
sudo snap set wekan header-login-email='BNPPEMAILADDRESS'

Docker

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

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

@lnvr

But does headers not include password? I would think that usually login to LDAP is with password.

@lnvr

This comment has been minimized.

Copy link

commented Mar 7, 2019

There are no passwords in the headers.
We use Kerberos as an authentication method.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

@lnvr

For Wekan LDAP username, do you currently use BNPPUID or BNPPEMAILADDRESS ?

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

Actually, my question above is irrelevant, because it could be changed in settings. Nevermind.

xet7 added a commit that referenced this issue Mar 8, 2019

xet7 added a commit that referenced this issue Mar 8, 2019

[HTTP header automatic login](ff825d6)
for [3rd party authentication server method](#2019) like siteminder, and any webserver that
handles authentication and based on it adds HTTP headers to be used for login. Please test.

Thanks to xet7 !

Related #2019

xet7 added a commit that referenced this issue Mar 8, 2019

Fix lint errors.
Thanks to xet7 !

Related #2019
@xet7

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

@lnvr

Please test latest Wekan, does it work. I don't know how it would be possible to login to LDAP without password, so maybe ID or something else could be used as password. If needed, you can also try setting default authentication method to LDAP at Admin Panel / Layout.

Snap

sudo snap set wekan header-login-id='BNPPUID'
sudo snap set wekan header-login-email='BNPPEMAILADDRESS'

Docker

export HEADER_LOGIN_ID=BNPPUID
export HEADER_LOGIN_EMAIL=BNPPEMAILADDRESS
@lnvr

This comment has been minimized.

Copy link

commented Mar 11, 2019

@xet7 Thank you ! I'll test it tomorrow at work and I'll let you know

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

@lnvr

Currently for Wekan LDAP login, with above settings email address is used as username/email and BNPPUID is used as password when logging in to LDAP.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

@lnvr

You can also set debug, to see are there errors when logging in:

Snap

Before trying to login

sudo snap set wekan debug='true'

After trying to login, to see logs

sudo snap logs wekan.wekan
sudo systemctl status snap.wekan.wekan

Docker

Before trying to login, in docker-compose.yml

export DEBUG=true

After trying to login, to see logs:

docker logs wekan-app
@hever

This comment has been minimized.

Copy link

commented Mar 12, 2019

I have problem with LDAP login. After hour of searching some debug log on server I find error on browsers console. It brings me to code if(a=req.headers[process.env.HEADER_LOGIN_EMAIL] and say req is not defined.

LDAP login completely fail.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 14, 2019

@lnvr @hever

I made some fixes and released Wekan v2.47. Please test does Wekan v2.47 work for you now.

@hever

This comment has been minimized.

Copy link

commented Mar 14, 2019

@xet7 now the error say "request is not defined" but still not work.

(Wekan v2.47)

@lnvr

This comment has been minimized.

Copy link

commented Mar 15, 2019

@xet7
I've tried to make it work with wekan v2.47, DEBUG=TRUE, HEADER_LOGIN_ID=BNPPUID, HEADER_LOGIN_EMAIL=BNPPEMAILADDRESS.
It does not work, also there is no logs with docker logs .
Did you make it work when you tested it ?

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

@lnvr

Sorry, I did not test it yet. I'm in progress of registering Siteminder trial account so that I could do some testing, and make it work.

It seems that changes I added did break LDAP login, so I need to revert some of those in next release. After that, I will make testing with Siteminder, and when it works, make new Wekan release.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

@lnvr

I did release Wekan v2.48 that makes LDAP login work again using normal non-siteminder LDAP login.

I did register for trial account at Siteminder, but they have not yet provided me with trial account.

There is no header login code enabled at Wekan v2.48, because currently I don't have any way to test any code changes with siteminder. So options are:
a) Wait until Sitemider company contacts me to provide trial account. Because today is friday, I would presume they contact me sometime next week.
b) You provide me a way to test my code changes with Siteminder. You can email me to x@xet7.org to provide details.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 19, 2019

@lnvr

Siteminder contacted me, and I registered as partner to SiteMinder Exchange, so their technology partner department will contact me and provide a way to test Wekan with SiteMinder. So there is progress.

@xet7

This comment has been minimized.

Copy link
Member

commented Mar 22, 2019

@lnvr

Today Siteminder connectivity partner department contacted me, so I provided link to this issue and info that I would need test account. I will wait for their answer.

xet7 added a commit that referenced this issue Apr 8, 2019

@xet7

This comment has been minimized.

Copy link
Member

commented Jun 6, 2019

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.

@xet7

This comment has been minimized.

Copy link
Member

commented Jun 6, 2019

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

export HEADER_LOGIN_DOMAIN=example.com

@xet7 xet7 removed this from In progress: by xet7, all paid and not paid Open Source Wekan work and all unrelated work. Order: from top to bottom of cards. in Wekan Roadmap Jun 6, 2019

@lnvr

This comment has been minimized.

Copy link

commented Jun 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.