can't use omniauth-cas within gitlab

moobyfr commented 11 years ago

Hi Using several modules in gitlab for auth such as ldap, or omniauth-google-oauth2 works fine. But If I use omniauth-cas (1.0.1), I get a backtrace:

omniauth: enabled: true allow_single_sign_on: false block_auto_created_users: true providers:

{ name: 'cas', host: 'cas.XXX.tld', login_url: 'cas/login/' }

==> unicorn.stderr.log <== /usr/local/lib/ruby/gems/1.9.1/gems/omniauth-1.1.1/lib/omniauth/strategy.rb:136:in initialize': Received wrong number of arguments. [nil, nil] (ArgumentError) from /usr/local/lib/ruby/gems/1.9.1/gems/omniauth-cas-1.0.1/lib/omniauth/strategies/cas.rb:58:ininitialize' from /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-3.2.9/lib/action_dispatch/middleware/stack.rb:43:in `new'

Is the error in omniauth-cas ?

dlindahl commented 11 years ago

Most likely. I just released 1.0.1 earlier in the week so it may contain a regression.

Try using 1.0.0 and see if you get the same error. In the meantime, I'll take a look at this in the next day or so.

moobyfr commented 11 years ago

I've tried with 1.0.0, same problem. I've tried with some modified gitlab.yml to mach more the parameters used for others modules:

providers:

{ name: 'cas', app_id: 'none', app_secret: 'none', host: 'cas.unistra.fr', login_url: 'cas/login/' }

==> /home/gitlab/gitlab/log/unicorn.stderr.log <== /usr/local/lib/ruby/gems/1.9.1/gems/omniauth-1.1.1/lib/omniauth/strategy.rb:136:in initialize': Received wrong number of arguments. ["none", "none"] (ArgumentError) from /usr/local/lib/ruby/gems/1.9.1/gems/omniauth-cas-1.0.0/lib/omniauth/strategies/cas.rb:58:ininitialize' from /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-3.2.9/lib/action_dispatch/middleware/stack.rb:43:in `new'

dlindahl commented 11 years ago

I don't think this is an OmniAuth CAS issue. It would appear that GitLab is passing in arguments that the CAS strategy is not designed to handle.

Can you provide a full stack trace?

I'd like to try and figure out what GitLab is trying to send to see if I can support it.

moobyfr commented 11 years ago

In the following gist is the full backtrace:

https://gist.github.com/4283548

courtarro commented 11 years ago

I'm dealing with this issue now, and I believe it has to do with GitLab assuming that every omniauth provider expects the app_id and app_secret parameters. Since omniauth-cas doesn't expect these parameters, I think things are breaking. I'm trying to track down the issue myself.

dlindahl commented 11 years ago

Has anyone been able to track down the problem with this yet?

jmatzan commented 11 years ago

Has there been any progress with this?

courtarro commented 11 years ago

The closest I got was to edit config/gitlab.yml and add the following lines to the existing "provider:" section:

providers:
    - { name: 'cas', app_id: '', app_secret: '',
        args: {
          host: 'login.sample.com',
          ssl: true,
          login_url: '/cas/login',
          service_validate_url: '/cas/serviceValidate',
          logout_url: '/cas/logout' } }

I was able to get a CAS image to appear on the login screen, and things generally worked until it got to the point where Gitlab tried to fetch name/email/etc. from the CAS server, at which point the process failed. I stopped working at that point because I didn't have time to figure out how to make the CAS server's SAML stuff work with Gitlab.

The bigger point is that Gitlab requires (or required at the time) a new user's full name and email in order to create a new account for each externally authenticated person. It seems like it would be best if Gitlab attempts to get that information, then instead of fully creating an account, shows the user the "new user" form and lets them complete their registration manually. If a user's full name and email aren't available from the auth server, it would require them to provide those details.

jmatzan commented 11 years ago

I just stumbled onto this pull request thread:

https://github.com/gitlabhq/gitlabhq/pull/3046

It looks like the email requirement problem was addressed, but it's hard to tell. I'm going to do the upgrade to 5.1 today and retry, using your configuration example.

steverweber commented 11 years ago

Any updates on this issue? im running branch 5.2 and cant seem to solve the CAS issue(s).

kohenkatz commented 11 years ago

@steverweber It does not yet work in 5.2. The pull request that @jmatzan mentioned is expected to be released in Gitlab 5.3, likely near the end of June.

dlindahl commented 11 years ago

Is it safe to say that this is a Gitlab issue and not related to the implementation of this particular OmniAuth strategy?

steverweber commented 11 years ago

yes; but the good news from what I can see the WIP patches for 5.3 should help clean up most of the issues. https://github.com/gitlabhq/gitlabhq/issues?direction=desc&milestone=21&sort=updated&state=open

dlindahl commented 11 years ago

Ok, I'm going to leave this open for now just in case this issue helps contribute to information exchange.

If someone could chime back in once Gitlab is fully compatible with this, then I'll close the issue.

kirantpatil commented 11 years ago

Hello

Will this feature (Omniauth-cas) land in GitLab v5.3 ?

Thanks.

dlindahl commented 11 years ago

@kirantpatil I doubt omniauth-cas will be included by default in GitLab, but I believe they are working on adding better support for OmniAuth strategies in general.

You'll have to follow the various links previously mentioned in this thread for more information.

steverweber commented 11 years ago

the patches got pushed back to the release 5.4

kirantpatil commented 11 years ago

Here is new pull request https://github.com/gitlabhq/gitlabhq/pull/4478

samrocketman commented 11 years ago

When I have gitlab configured with CAS through omniauth I find that the service ticket is requested with one URL and validated against a completely different URL. It seems to be double encoding the URL string somewhere. I don't really know ruby though I can kind of tell what is going on by reading through the code. Do you think something like this would be a gitlab problem or an omniauth-cas problem? Sounds more like omniauth-cas to me but I could be wrong.

Due to the validation happening through a different double encoded URL I get the response 'Invalid Ticket' from CAS. In the CAS logs it actually shows the request coming in for a ticket in one URL and the validation happening for a similar yet double encoded URL.

dlindahl commented 11 years ago

Any new updates on this? @sag47, can you provide any more information?

samrocketman commented 11 years ago

@dlindahl The double encoding was an apache misconfiguration. However, the app server is sitting behind a SSL proxied front end. So validation URLs are not receiving the correct protocol (https vs http) when calling the ticket validation. However, when the ticket is first requested it does successfully utilize https because it is using the referrer.

So the double encoding was a false problem but the URL requesting the ticket and the URL validating the ticket vary because of the https proxy.

I was able to force https in omniauth-cas which was useful for validation. After that, I realized that we aren't using the CAS protocol but the saml protocol. In any case, someone using the CAS protocol would encounter that issue. For now, I've stopped using omniauth-cas until I can figure something out with the CAS server.

dlindahl commented 10 years ago

Does anyone have any updates as to the status of omniauth-cas and gitlab?

samrocketman commented 10 years ago

As of right now I was not able to get it to work with my set up. But that's because I found out we're using SAML validation in Jasig CAS. I'm still going to work with our CAS admin and try to expose the proper information via CAS protocol. I also still need to provide you with a SAML sample in another issue so that you can determine whether or not to support SAML.

pencil commented 10 years ago

We are using ominauth-cas in our GitLab installation. Documented the procedure here: https://github.com/gitlabhq/gitlab-public-wiki/wiki/Working-Custom-Omniauth-Provider-Configurations#working-cas-configuration

samrocketman commented 10 years ago

@pencil Are you using SSL? I discovered an omniauth-cas bug in my setup where if the frontend was terminated using SSL then omniauth-cas would still hand off http urls to the CAS service. I have yet to completely confirm it which is why I haven't filed an issue (i.e. since we're not using CAS protocol but SAML). I saw the behavior when listening to network connections via firebug and found the affected lines of code and fixed it in my instance.

pencil commented 10 years ago

Yes, we are using SSL. Don't have the problems you described.

volfco commented 10 years ago

@pencil I am trying to get this configured with the steps you linked to, but I am still getting an ArgumentError ( Received wrong number of arguments. nil, nil) stemming from gitlab.yml. Is there anything else you are doing in your setup that you did not mention on the page you linked to?

pencil commented 10 years ago

We are still on version 4.x, so maybe that's why it works here :grin: Try it without the changes in gitlab.yml. Not sure those were really necessary.

volfco commented 10 years ago

Thanks, that worked. Now it redirects to CAS but now I am getting a Internal Server Error on the callback. The production.log is giving the following error NoMethodError (undefined methodcas' for #):` Any more ideas?

steverweber commented 10 years ago

I think remote auth is supported? So another method could be to use mod_auth_cas and proxy pass from Apache.

gdmalet commented 10 years ago

I am getting the `wrong number of arguments' error with gitlab 6-1-stable and omniauth-cas 1.0.2 and now 1.0.4 direct from the Gitlab repo.

My gitlab.yml looks like this:

 - { name: 'cas', app_id: 'cas_app', app_secret: 'xyzzy',
    args: { host:  [...]

... and with that 'cas_app' and 'xyzzy' are logged as being problematic. I can work around this by doing thusly in strategies/cas.rb:

  def initialize( app, *args, &block )
  # We drop the app_id & app_secret args, as they're not used. See config/gitlab.yml
  # super
    super(app, *args.drop(2), &block)
  end

The above existed in 1.0.2 with just the call to super. In 1.0.4 that function doesn't exist, so I added it. Seems gitlab insists on passing those args.

Hope this is useful.... I can give more details if you need them.

samrocketman commented 10 years ago

@gdmalet you need to first follow the configuration recommendation in the gitlab public wiki.

https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations#working-cas-configuration

gdmalet commented 10 years ago

@sag47 Thanks for tip, but I think the information in the gitlab wiki is wrong / old / redundant? The parameters it suggests in config.omniauth are now specified in config/gitlab.yml:

    - { name: 'cas', app_id: 'cas_app', app_secret: 'xyzzy',
    args: { host: 'cas.wherever.com',
            service_validate_url: '/cas/serviceValidate/',
            ssl: true,
            disable_ssl_verification: true,
            login_url: '/cas/login/',
            logout_url: '/cas/logout' } }

I'm new to all this so I could be completely wrong, but I hope not :-)

kirantpatil commented 10 years ago

I too have below same issue with latest GitLab v6.3.1. I followed https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations.

Where should I need to configure ?

from /usr/local/bin/unicorn_rails:23:in `load'
from /usr/local/bin/unicorn_rails:23:in `<main>'

I, [2013-12-17T09:52:17.951789 #12497] INFO -- : Refreshing Gem list /usr/local/lib/ruby/gems/1.9.1/gems/omniauth-1.1.4/lib/omniauth/strategy.rb:143:in `initialize': Received wrong number of arguments. nil, nil

samrocketman commented 10 years ago

As I stated before the working cas configuration in my previous post is the recommended way to do it. Omniauth-cas has no app_id nor app_secret. The information is not wrong. I configured it myself and even though I couldn't get my own set up working that's only because we use SAML auth rather than CAS 2.0 for auth. In any case, TCP dump, logs, and otherwise indicated that it still works and is current for GitLab 6.3.

kirantpatil commented 10 years ago

Yes, I followed the same from the gitlab public wiki and got that error and gitlab does not come up. Have I done anything wrong in the configuration? Please guide me to resolve the issue.

gdmalet commented 10 years ago

@sag47, have you tried your suggested configuration with recent software? Doing as you suggest results in:

ArgumentError (:host and :login_url MUST be provided): [...]omniauth/strategies/cas.rb:143:in `validate_cas_setup'

There is definitely a problem, either with documentation, or with the software, and I'm sure many people here are willing to help sort it out. But first we need to actually agree there is a problem! We are getting nowhere currently.

samrocketman commented 10 years ago

@gdmalet You have to use that method of configuring in gitlab. However, you need to use the arguments of the version of omniauth-cas that you're using. So granted, those args are not valid for likely the version of omniauth-cas that you're using.

See omniauth-cas README for usage.

If you look at the source of the error you'll see cas.rb:134 in the latest master.

:login_url has a default setting.
:host is automatically extracted from the :url.

You'll have to post what you're using in devise.rb. Also, what version of omniauth-cas are you using? If possible point to the version you're using in the git repository. Like I said; when I originally tested it it seemed to work aside from my own server misconfigurations.

abargutu commented 10 years ago

Hi, i'm using gitlab 6.9 with omniauth-cas and it validates two times....why log apears ticket_validated and ticket_invalidate

abargutu commented 10 years ago

what kind of local passwords saves gitlab when u validate with cas??

dlindahl commented 10 years ago

Anyone have any success with GitLab lately?

steverweber commented 10 years ago

Personally: I would try to migrate away from CAS.

novaforge commented 10 years ago

Hi, I'm trying to use omniauth-cas v1.1.0 with Gitlab 7.3.1 and I got some troubles on CAS Logout.

Firstly, Gitlab does not work yet with omniauth 1.2.0, so i had to downgrade the dependence to omniauth 1.1.0 into omniauth-cas.gemspec.

Secondly, I got any trouble to login with CAS, but on the log out using /cas/logout, omniauth-cas crash because I do not know how to use option "on_single_sign_out" :

Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"logoutRequest"=>"<samlp:LogoutRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" ID=\"LR-6-ztDqay1xsaBBxderXxmkfZGnEH5CNG6h6yU\" Version=\"2.0\" IssueInstant=\"2014-11-14T14:52:03Z\"><saml:NameID xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\">@NOT_USED@</saml:NameID><samlp:SessionIndex>ST-6-P4Z4Sr2WbtxLBnOwcvL5-cas01.example.org</samlp:SessionIndex></samlp:LogoutRequest>", "url"=>"https://gitlab/gitlab-default/gitlab/users/sign_in"}
Can't verify CSRF token authenticity
Redirected to https://gitlab/gitlab-default/gitlab/users/sign_in
Completed 302 Found in 8ms (ActiveRecord: 0.0ms)

NoMethodError (undefined method `[]' for nil:NilClass):
  rack (1.5.2) lib/rack/etag.rb:30:in `call'
  rack (1.5.2) lib/rack/conditionalget.rb:35:in `call'
  rack (1.5.2) lib/rack/head.rb:11:in `call'
  actionpack (4.1.1) lib/action_dispatch/middleware/params_parser.rb:27:in `call'
  actionpack (4.1.1) lib/action_dispatch/middleware/flash.rb:254:in `call'
  rack (1.5.2) lib/rack/session/abstract/id.rb:225:in `context'
  rack (1.5.2) lib/rack/session/abstract/id.rb:220:in `call'
  actionpack (4.1.1) lib/action_dispatch/middleware/cookies.rb:560:in `call'
  activerecord (4.1.1) lib/active_record/query_cache.rb:36:in `call'
  activerecord (4.1.1) lib/active_record/connection_adapters/abstract/connection_pool.rb:621:in `call'
  actionpack (4.1.1) lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
  activesupport (4.1.1) lib/active_support/callbacks.rb:82:in `run_callbacks'
  actionpack (4.1.1) lib/action_dispatch/middleware/callbacks.rb:27:in `call'
  actionpack (4.1.1) lib/action_dispatch/middleware/remote_ip.rb:76:in `call'
  actionpack (4.1.1) lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
  actionpack (4.1.1) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
  railties (4.1.1) lib/rails/rack/logger.rb:38:in `call_app'
  railties (4.1.1) lib/rails/rack/logger.rb:20:in `block in call'
  activesupport (4.1.1) lib/active_support/tagged_logging.rb:68:in `block in tagged'
  activesupport (4.1.1) lib/active_support/tagged_logging.rb:26:in `tagged'
  activesupport (4.1.1) lib/active_support/tagged_logging.rb:68:in `tagged'
  railties (4.1.1) lib/rails/rack/logger.rb:20:in `call'
  actionpack (4.1.1) lib/action_dispatch/middleware/request_id.rb:21:in `call'
  rack (1.5.2) lib/rack/methodoverride.rb:21:in `call'
  rack (1.5.2) lib/rack/runtime.rb:17:in `call'
  rack (1.5.2) lib/rack/lock.rb:17:in `call'
  rack (1.5.2) lib/rack/sendfile.rb:112:in `call'
  railties (4.1.1) lib/rails/engine.rb:514:in `call'
  railties (4.1.1) lib/rails/application.rb:144:in `call'
  railties (4.1.1) lib/rails/railtie.rb:194:in `public_send'
  railties (4.1.1) lib/rails/railtie.rb:194:in `method_missing'
  rack (1.5.2) lib/rack/builder.rb:138:in `call'
  rack (1.5.2) lib/rack/urlmap.rb:65:in `block in call'
  rack (1.5.2) lib/rack/urlmap.rb:50:in `each'
  rack (1.5.2) lib/rack/urlmap.rb:50:in `call'
  unicorn (4.6.3) lib/unicorn/http_server.rb:552:in `process_client'
  unicorn-worker-killer (0.4.2) lib/unicorn/worker_killer.rb:51:in `process_client'
  unicorn (4.6.3) lib/unicorn/http_server.rb:632:in `worker_loop'
  unicorn (4.6.3) lib/unicorn/http_server.rb:500:in `spawn_missing_workers'
  unicorn (4.6.3) lib/unicorn/http_server.rb:142:in `start'
  unicorn (4.6.3) bin/unicorn:126:in `<top (required)>'
  /opt/gitlab/embedded/service/gem/ruby/2.1.0/bin/unicorn:23:in `load'
  /opt/gitlab/embedded/service/gem/ruby/2.1.0/bin/unicorn:23:in `<main>'

Here is my "simple" configuration file :

providers:
      - {"name":"cas","args":{"host":"gca","path":"/cas","disable_ssl_verification":true}}

Any idea on how to configure "on_single_sign_out" option would be nice ;)

Of course, I'm new to Ruby ;)

Cheers,

dlindahl commented 10 years ago

@novaforge this sounds like an issue that differs from the original reporter. Can you open a new issue so we can move the discussion there?

surmountli commented 9 years ago

use omniauth-cas 1.04 ,gitlab 7.2.1

gitlab.yml-------- providers:

{"name":"cas"} devise.rb--------------- config.omniauth :cas,
host: 'XXXX.com',

port: '443',

url: 'https://XXXX.com', ssl: true, ca_file: 'XXXX.crt', login_url: '/', logout_url: '/',

service_validate_url: '/cas/serviceValidate',

disable_ssl_verification: true

modify omniauth_callbacks_controller.rb --------------- def cas ..... ....... end

i can login ,login out , the problem is

can't do ssl verification,if i set disable_ssl_verification: false ,report 500 error, openssl error like this OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed):
the parameter ca_file: 'XXXX.crt', can use in 1.04? @dlindahl

2、i test the crt file like this openssl s_client -connect XXXX:443 -CAfile /home/git/crt/XXXX.crt return 0, is ok? any thing wrong? should i use pem file in ca_file set ? @dlindahl

samrocketman commented 9 years ago

@surmountli Please create a new issue rather than commenting off topic in this one.

moobyfr commented 9 years ago

Hi I'm the author of the initial issue. The error as described doesn't show anymore with gitlab 7 (+onmiauth-cas 1.0.4), but there is still a issue: Gitlab requires at least two entries: email and user. In a basic CAS server, the response has only the user in response. If the CAS server is configured to transmit more entries, they are stored by omniauth-cas .

Forcing to reply with a fixed email makes this omniauth module operational.

It seems that the parameter fetch_raw_info could be a solution to force an email (I would prefer to be able to call the omniauth-ldap module to retrieve the ldap attributes, but I don't know enough ruby for now)

dlindahl commented 8 years ago

I no longer have access to a CAS server and therefore am no longer fit to maintain this project.

If you would like to volunteer to be a maintainer of this project, please let me know by opening an Issue.

skywalkerjc commented 8 years ago

I try to add onmiauth-cas 1.1.0 to my gitlab-v8.8.0 with gem install onmiauth-cas, and I exactlly folowed Installation, I add

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :cas, host: 'cas.yourdomain.com'
end

to gitlab/config/initializers/omniauth.rb but run error Refreshing Gem list Devise::OmniAuth::StrategyNotFound: Could not find a strategy with nameCas'. Please ensure it is required or explicitly set it using the :strategy_class option`

then I tried to follow https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations add config.omniauth :cas, url: 'https://sso.example.com/', disable_ssl_verification: false to gitlab/config/initializers/devise.rb , but the same error info, is there any thing I miss out, please help me. Thx

danschmidt5189 commented 5 years ago

Works fine with our GitLab 11.x instance. Closing — reopen if there's interest and test cases.

dlindahl / omniauth-cas

can't use omniauth-cas within gitlab #7

host: 'XXXX.com',

port: '443',

service_validate_url: '/cas/serviceValidate',