Is single sign on on the road map? Anyone working on a CAS plugin?
Nobody I know is working on it, but omniauth has a strategy.
Do we have a HOWTO about integrate omniauth-* ?
So I have done a slightly better than rough version of the integration at GitHub - eriko/discourse: A platform for community discussion. Free, open, simple. and I have put in a pull request to get some feedback (probably not the best way). Add CAS authentication via the CAS strategy of omniauth by eriko · Pull Request #873 · discourse/discourse · GitHub
Here is what CAS adds. A large number of colleges and universities use CAS for single signon. They, like my school, generally require it for supporting an application to be accessed by their students. It was one of the earlier implementations of SSO and does suffer from the lack of extra data being returned like an email address or name. It does work well and has a lot usage in .edu .
I have pulled the pull request while I rework the patch to remove some debug cruft and make it a bit more flexible in the config setup for CAS. The structure of CAS urls can be a bit variable.
After a bit of work (cleanup and tests) I have sent a new pull request. (that I can not link to as I have linked to many times for a new member on discourse)
Thanks – FYI, you also ran into a small bug with our link spam protection for new users, we’ll get that cleaned up soon. I’m glad we discovered it because it is subtle! (about # of links versus # of posts…)
edit: the bug with the link spam protection for new users should be fixed now.
Has this SSO CAS integration made its way into Discourse? I am running a CAS server in my organization and would like to integrate it with Discourse.
The current integration is working to the point where Discourse forwards login request to SSO, SSO asks for credentials, verifies, and returns user to Discourse. However, Discourse still shows ‘Log In’ since the user possibly doesn’t exist in the Discourse DB. So the SSO integration needs to be able to create a user in Discourse if it doesn’t exist already.
Any suggestions on how to proceed?
CAS is supported via 3rd party applications to communicate between discourse’s build in SSO and CAS for auth.
Discourse automatically creates the user if that user doesn’t exist. That’s not going to be your problem.
I’m not an expert on the SSO, but try checking if the email and username mappings appear in your CAS’ return payload – a user needs a valid email to be created, otherwise Discourse SSO will not work.
…I’m assuming you’re using @eriko’s SSO solution - GitHub - eriko/discourse_cas_sso: An app that proxy connects CAS authentication to discourse via the discourse sso api There’s no way for discourse to handle connecting to a CAS server directly.
One side note is that if you can set your CAS implementation up to provide SAML then there is a saml plugin that the Discourse folk wrote. GitHub - discourse/discourse-saml: Support for SAML in Discourse If you are using a recent version of Jasig CAS then it can do SAML. Otherwise the SSO proxy that @awole20 mentioned is your only path.
Appreciate the feedback, guys.
I am going the path of standing up GitHub - eriko/discourse_cas_sso: An app that proxy connects CAS authentication to discourse via the discourse sso api as a mediating service between Discourse and CAS. I have this integration working but am running into “Account login timed out, please try logging in again” on random logins - whether the user is new or existing in Discourse. How can I address this?
I have run in to this also and it seems to be an issue with the timeout for the nonce that discourse sends to my app and then back to discourse. If the stack discourse > discourse_cas_sso > cas > discourse_cas_sso > discourse is running on slow hardware (a couple vm’s on your desktop) it is much more likely to happen. I think there was some discussion about extended this timeout but I do not remember what can of it.
Where would the timeout need to be extended? CAS Server? or Discourse? Does Discourse have a configurable and exposed setting to tinker with the timeout?
In discourse and at the time it was not exposed.
I was wrong about the Nonce being to short. It is set to 10 minutes. That being the case the timeout on the CAS server might be enough. On out JASIG CAS setup it is set to 10 seconds.
Let me ask an other question. Since you seem to be setting up your own cas server I question the path you are going down. I really only recommend people use CAS with Discourse if they already have the a fully setup CAS infrastructure in place. There are better ways to do auth than CAS. Even using local accounts and requiring that all the email addresses come from your domain is better than maintaining the CAS stuff.
Also if you are going to go production with your own CAS setup you should really looking in to the JASIG CAS stuff it has much more support than casino.
The reason I went with CAS and CASino was because it seemed quite straightforward to set up and checked off the feature list for what my organization is looking for.
What would you recommend instead of CAS protocol? And which associated project?
What other tools are you using? Windows + exchange environment? If you are using the Azure stuff it supports SAML natively and there is a plugin for that.
Basically what I am saying is that unless you are required to have an existing SSO environment then CAS is a lot of extra stuff to run just for discourse. Using just the existing local account mechanism with requirement that they use email address from domains that you control ‘email domains whitelist’ to create an accounts gives you pretty much the same behaviour you get if you are only using CAS for discourse and not any other services.
I am using SSO for other services as well - Discourse is just one of them.
Ok then it makes more sense. I would still suggest looking at Jasig CAS as it is more fully featured and maintained.
The timeout is hardcoded to 10 minutes here:
Needing more that 10 minutes from the time people click on “login” till the time you go back to “discourse” seems excessive to me.
That said this has happened before, we could issue a redirect back to the SSO endpoint that would issue the sequence again or at least clean up that page that shows the error.