jbittel / django-mama-cas

A Django Central Authentication Service (CAS) single sign-on server
BSD 3-Clause "New" or "Revised" License
395 stars 112 forks source link

Jenkins plugin doesn't work properly with mama-cas, developer suggests it might be mama-cas bug #19

Open ghost opened 9 years ago

ghost commented 9 years ago

Currently, the jenkins CAS plugin doesn't work with mama-cas when in SAML 1.1 mode (CAS 2.0 on the other hand works fine). Jenkins plugin bug ticket: https://issues.jenkins-ci.org/browse/JENKINS-28568

The jenkins plugin appears to be using this TARGET parameter (visible as GET parameter) for the /login endpoint. However, according to https://github.com/Jasig/cas/blob/master/cas-server-documentation/protocol/CAS-Protocol-Specification.md in section 2.1.1, the /login endpoint only knows the "service" parameter, but not explicitly the TARGET parameter.

The SAML 1.1 specification section 4.1.1.3 (https://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf) specifies such a generic TARGET parameter for any sort of SAML request. The plugin developer also tells us that (unlike mama-cas) the Jasig/Apereo CAS server interprets this parameter the same way as the "service" one.

Either mama-cas or the jenkins plugin seem to be not fully operating to the specs, although I certainly cannot tell with my limited knowledge. Therefore it would be nice if you could figure out which side needs to fix things so this can finally be resolved in whatever way is the best.

jbittel commented 9 years ago

Right off, I realized that /samlValidate was accepting the TARGET parameter as lowercase, which is obviously incorrect. I pushed up a642ad09257b231f3ad1abdfc3aaff0a864c0b43 which fixes that specific problem. If you could give that a try and see if that fixes the Jenkins integration, I would appreciate it.

The SAML support has not received as much real-world testing as I would like, so please feel free to report any other issues you may run across. Thanks!

ghost commented 8 years ago

This still seems to be a problem for the /login view, where the jenkins CAS plugin appears to use TARGET as well (according to the author that is because of the SAML spec 4.1.1.3 at https://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf ). So while ccas_saml_validate does handle the parameter now, the login still doesn't work with mama-cas and the jenkins CAS plugin combined.

The jenkins plugin bug report is here: https://issues.jenkins-ci.org/browse/JENKINS-28568

I'm not sure if the CAS Protocol Specification Section 2 .1.1 "parameters" should apply here for the /login view or the SAML specification as well with their "TARGET" parameter. The jenkins plugin author seems to currently assume the latter. You two might wanna exchange a few messages on what is the right course of action here :-) so this can be fixed on the respective side of things

jbittel commented 8 years ago

Thanks for the update, I'll see if I can track down what's going wrong here.

manelclos commented 6 years ago

Hi, I installed jenkins and tried to log in using the CAS plugin using SAML 1.1, it sends the request to the CAS server:

http://xenial.local/apps/cas_internal/login?TARGET=http%3A%2F%2Fxenial.local%3A8080%2FsecurityRealm%2FfinishLogin

mama-cas LoginView has been modified to also read TARGET parameter if service is not available (line 146):

        service = self.request.GET.get('service', self.request.GET.get('TARGET'))

When login in, you get this redirect to jenkins:

http://xenial.local:8080/securityRealm/finishLogin?ticket=ST-1519855323-ol0D4SEQd9BpCcyLjQY4eXHTrG7j0Jj1

Which fails, there is also no request to mama-cas, and you get this page:

http://xenial.local:8080/securityRealm/failedLogin

The linked specification seems to indicate that the redirect should be different (so we need to act different for service and TARGET parameters), it should contain TARGET and SAMLart parameters set.

Would be great to get some directions here :)