Single Sign On error on CAS Auth

sso

(ikbear) #1

I got an error like this:

Does it mean that I have to make Discourse https when using a CAS Auth Single Sign On?


(eriko) #2

My only guess is that your CAS server is not configured correctly. Both cas_sso and cas need to be running under SSL as they are passing around authentication material.

Is your CAS server running one https or http?


(eriko) #3

You need a real certificate when you are running in production. You can add
disable_ssl_verification: true
to config/initializers/omniauth.rb to disable validation.

Mor information here GitHub - dlindahl/omniauth-cas: A CAS OmniAuth Strategy


What is the procedure to obtain CAS between my website and my discourse instance?
(ikbear) #4

I have enable ssl in test environment


(Kane York) #5

Then you need to add the CA to the server’s trust store. Use the app.yml run: section to copy the file in.


(ikbear) #6

Which file? SSO or Discourse?

I just test it on my own machine, don’t know why it is so inconvenient.


(eriko) #7

cas-sso. This will stop omniauth from verifying the DSL certificate. You will need to turn this off before you run in production.


(eriko) #8

Let me ask a question? Why are you looking at using CAS? Generally people that trying to add this to discourse already have CAS setup and running at their school and It is mandated that they use it. You seem to be setting up a full system from scratch and this makes me wonder why you are using CAS as it is a hard road if you are not being forced to use it.


(ikbear) #9

I my production environment, I set my CAS server’s URL to: https://cas.qiniu.io:9443, but it returns this error:

Failed to create or lookup user: Validation failed: Email can’t be blank
nonce: c24cd3733c0205cef3c9b46bf7516f31
name: helishi
username: helishi
email:
avatar_url:
avatar_force_update:
require_activation:
about_me:
external_id: helishi
return_sso_url: http://discourse.dev/session/sso_login
admin:
moderator:
suppress_welcome_message:

I guess it is because my production CAS server can’t return user’s email address. But I don’t have access to my production server’s log. So I test CAS Server in my local machine by changing the config file to this:

authenticator:
class: CASServer::Authenticators::Qiniu
host: '127.0.0.1’
port: 27017
db: 'qbox’
collection: 'user’
extra_attributes: ‘roles, email, mobile, qq, github’

My local CAS Server’s log shows that the return information is correct:

Processing CASServer::Server::call {“username”=>“helishi”, “password”=>"******", “lt”=>“LT-1435512297rvGPh6KarzG-p0QgGCQ”, “service”=>“http://sso.dev/auth/cas/callback?url=http%3A%2F%2Fdiscourse.dev%2F”}
Validating login ticket 'LT-1435512297rvGPh6KarzG-p0QgGCQ’
Login ticket ‘LT-1435512297rvGPh6KarzG-p0QgGCQ’ successfully validated
Generated login ticket ‘LT-1435512300rmV1SiMbQVGf1QkeSBv’ for client at 'localhost’
Logging in with username: helishi, lt: LT-1435512300rmV1SiMbQVGf1QkeSBv, service: http://sso.dev/auth/cas/callback?url=http%3A%2F%2Fdiscourse.dev%2F, auth: [CASServer::Authenticators::Qiniu]
CASServer::Authenticators::Qiniu will try to extract the following extra_attributes: [“roles”, “email”, “mobile”, “qq”, “github”]
Credentials for username ‘helishi’ successfully validated using CASServer::Authenticators::Qiniu.
Authenticator provided additional user attributes: {“roles”=>"", “email”=>"helishi@qiniu.com", “mobile”=>“18516515116”, “qq”=>“591515408”, “github”=>“ikbear”}
Generated ticket granting ticket ‘TGC-1435512300rgpAA1qQqREPg9Yz2JX’ for user ‘helishi’ at ‘localhost’ with extra attributes {“roles”=>"", “email”=>"helishi@qiniu.com", “mobile”=>“18516515116”, “qq”=>“591515408”, “github”=>“ikbear”}
Ticket granting cookie ‘#<CASServer::Model::TicketGrantingTicket id: 11, ticket: “TGC-1435512300rgpAA1qQqREPg9Yz2JX”, created_on: “2015-06-29 01:25:00”, client_hostname: “localhost”, username: “helishi”, extra_attributes: {“roles”=>"", “email”=>"helishi@qiniu.com", “mobile”=>“18516515116”, “qq”=>“591515408”, “github”=>“ikbear”}>’ granted to "helishi"
Generated service ticket ‘ST-1435512300rDn1jSFtnbpYiiVWqPz’ for service ‘http://sso.dev/auth/cas/callback?url=http%3A%2F%2Fdiscourse.dev%2F’ for user ‘helishi’ at 'localhost’
Redirecting authenticated user ‘helishi’ at ‘localhost’ to service ‘http://sso.dev/auth/cas/callback?url=http%3A%2F%2Fdiscourse.dev%2F

It returns to CAS SSO server after Authenticating: http://sso.dev/auth/cas/callback?url=http%3A%2F%2Fdiscourse.dev%2F

But it stops at a SSL error like my first pic, and that error makes it can’t return me to Discourse app.


(eriko) #10

You need is disable ssl verification in your test instance of cas_sso so that you can use you test instance of rubycas-server that is setup to return an email address.

No matter what you do you need to have a CAS server that returns an email address.


(ikbear) #11

So where to disable all SSL? I change this file like this:

And CAS Server works over http is ok.


(eriko) #12

That looks correct to me. Have you set up your CAS server to send an email address? This will not work unless you CAS server returns an email address.


(ikbear) #13

My CAS Server return something like this:

I think it’s correct, but don’t sure whether the xml file’s format is correct.


(eriko) #14

There are two CAS do format Janis and rubycas both are supported by omniauth CAS.

Now that you have both email issue and have turned off ssl verification things should be working. When you move to product you need to reenable ssl for the CAS server.


(ikbear) #15

What I show you last time is returning from my production’s https based CAS Server. But the Discourse still returns me something like this:

Error updating information, contact site admin

I have seen a issue from here that the return xml should be like this: Google Code Archive - Long-term storage for Google Code Project Hosting.


(eriko) #16

Some cas servers return separate cas:attributes elements and some do not. The omniauth-cas gem handles both. You might see if there is a conflicting account with the same email address that you are trying to use. The “sso overrides *” could be part of that.

To see what is being sent back to discourse you could use some thing like
logger.info "sso return email #{sso.email}"
logger.info "sso return mail #{sso.mail}"
logger.info “sso return name #{sso.name}”


(ikbear) #17

sso return email is blank.

There is no any conflict between accounts.


(ikbear) #18

logger.info request.env[“omniauth.auth”]

it prints like this:

#<OmniAuth::AuthHash credentials=#<OmniAuth::AuthHash ticket="ST-1435552070r8SiMFjyd2Lwrn76X31"> extra=#<OmniAuth::AuthHash user="helishi"> info=#<OmniAuth::AuthHash::InfoHash email="helishi@qiniu.com" nickname="helishi"> provider=:cas uid="helishi">

I guess I get something to extract the correct email address.


(eriko) #19

Hmm is looks like omniauth-cas is not putting the email address in to the extra element request.env["omniauth.auth"][:extra]

Ok try this change
email = request.env["omniauth.auth"][:extra][configatron.cas.email_attribute] in cas_sso/app/controllers/login_controller.rb to

if request.env["omniauth.auth"][:extra][configatron.cas.email_attribute] email = request.env["omniauth.auth"][:extra][configatron.cas.email_attribute] else email = request.env["omniauth.auth"][:info][configatron.cas.email_attribute] end

This will look in the info hash and not in the extra hash. If that works I will have to see what omniauth-cas is not handling you cas xml corretly.


(ikbear) #20

That’s right, I extract it from :info. Maybe you should fix it in your sole SSO App.