[suggestion] add single-sign on support for popular service, e.g., Google, Facebook, Twitter

[aixnr]

It would be great of Let's Chat has the options for SSO. How about using the PassportJS?

[MitchK]

I have started to create a module for GitHub/GitHub Enterprise: https://github.com/sdelements/lets-chat/issues/341

[npotier]

+1

[rawlingsj]

+1

Is there already work on this? If so then I'd happily start looking at adding support for OpenShift OAuth too. We're looking at integrating Lets Chat with the fabric8 project which sits on OpenShift v3 (a docker/kubernetes based PaaS for on premise or public cloud: http://www.openshift.org/)

[vwbusguy]

A general SAML would be great as we use Shibboleth and JASIG CAS here at work, though we can handle that in a separate if necessary. Google, for instance, uses SAML for its services.

[vwbusguy]

As a reference to OP: https://github.com/bergie/passport-saml . Looks like PassportJS would cover a lot of ground.

[dyerti]

I have a working SSO example using gitlab is the SSO provider: https://github.com/dyerti/lets-chat/tree/gitlab-sso https://github.com/dyerti/lets-chat-gitlab

It required an auth plugin API change.

@sibartlett if you have sometime can you take a look?

I changed the auth plugin prototype to provider.authenticate(req, res, callback) since the passport SSO plugins need to modify the response.

I standardized the prototype of auth.authenticate(req, res, callback). I haven't I hit everything that called auth.authenticate previously. Need to work through handling XMPP.

It's not really ready for a PR, but wanted to see if this seemed to be a reasonable approach?

[dyerti]

A big question is how to handle XMPP when an account is authenticated with SSO. My current approach is to allow a token to be used in place of a password when authenticating an XMPP connection.

Login screen is another question. I'm going to test somethings out here, but the jist is the username/password would not be presented if logging in using SSO.

[dyerti]

A passportJS limitation, providers can't be chained after a redirect. If you want to use both a SSO service and local. You need to have local as higher priority as the SSO redirect will break the chain:

auth:
  providers: [local, gitlab]

It might make sense to be a little more explicit on login, specifying provider at login time on the web side. This would simplify authentication and remove the need for the async.waterfall chain. XMPP login with user and password can still be chained and the SSO token check done before that.

[dyerti]

I have working XMPP with tokens, update signin page with SSO buttons and preliminary github support.

https://github.com/dyerti/lets-chat-github

I'll going to throw together a google login example tomorrow, which should hit #269 as well. UI still needs a little work, but almost everything should be functional.

[npotier]

Hello @dyerti, any news on your work to create a login example with google ?

Thanks :)

[hhaidar]

@npotier I think this it: https://github.com/dyerti/lets-chat-google

[npotier]

@hhaidar thanks ! I'll try it.

[dyerti]

It requires some changes that haven't been merged.

Fastest way to test it out:

git clone https://github.com/dyerti/lets-chat.git
git clone https://github.com/dyerti/lets-chat-google.git

cd lets-chat
git checkout gitlab-sso
npm install
npm install ../lets-chat-google

<edit settings.yml>

npm start

The auth section of settings.yml is covered in the README: https://github.com/dyerti/lets-chat-google/blob/master/README.md

[craSH]

Hello! Is there any plan to have this work / SAML support integrated into the main repository? This issue/thread seems to have gone quiet for quite a while.