Ha ha ha ok, sorry, you already tried that link I sent. (Sigh)
Maybe try again after you confirm success through the gui? When I do this it's against jenkins deployed to weblogic. I use a deployment plan to transform web.xml to add CLIENT-CERT to auth config and then configure the security realm to map client certificates to users then set jenkins to delegate. Jenkins ends up thinking it did a form based auth when really weblogic did all the work and all the client did was provide a certificate. It's a niche setup and probably not appropriate for what you're doing but I get out of having to deal with what you are at the moment. I apologize but I really am stumped after this. I suppose you could go back to one of your original concerns and unpack the war, change the auth config to BASIC, repack it and try again, just to eliminate that as a concern. On Jun 12, 2014 1:18 PM, "Ben Castellucci" <ben...@gmail.com> wrote: > If login through gui works OK then try token based [1] and see if that > works. > > Other than that I am stumped. > > [1] > https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients > On Jun 12, 2014 12:53 PM, "Ben Castellucci" <ben...@gmail.com> wrote: > >> A good test to see if jenkins properly recognizes the container role is >> if it does not offer a delete option next to the role in the matrix >> security config. >> >> Also, looks like you're trying form based and trying to get curl to store >> the session cookie. You might try basic auth instead. >> >> Out of curiosity can you log in through the gui with this setup? If that >> works then there's nothing wrong with the auth setup and the problem is >> with curl (for whatever reason). >> On Jun 12, 2014 11:10 AM, "Scott Cowan" <scott.cowan....@gmail.com> >> wrote: >> >>> Thank you Robert and Ben for your tips. >>> >>> This is the closest I've been able to come to reproducing the form-based >>> authentication captured with wireshark. >>> >>> curl -v -c cookies.txt http://localhost:8080/jenkins/ >>> 200 OK >>> curl -v -c cookies.txt -b cookies.txt >>> http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F >>> 200 OK >>> curl -v -c cookies.txt -b cookies.txt -H "Referer: >>> http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F\r\n >>> <http://localhost:8080/jenkins/loginEntry?from=%2Fjenkins%2F%5Cr%5Cn>" >>> -d "j_username=admin&j_password=admin" >>> http://localhost:8080/jenkins/j_security_check >>> 302 Found >>> curl -v -c cookies.txt -b cookies.txt -X POST >>> http://localhost:8080/jenkins/job/test/build?delay=0sec >>> 403 Forbidden (authenticated as anonymous) >>> >>> So, I'm unsure if my POST to j_security_check didn't work, or if the >>> roles in my tomcat-users.xml aren't being mapped auto-magically. I've read >>> through some tomcat docs (http://tomcat.apache.org/tomcat-7.0-doc/), >>> but I'm really not sure what I'm looking for. >>> >>> Scott >>> >>> tomcat-users.xml >>> ... >>> <role rolename="admin"/> >>> <user username="admin" password="admin" roles="manager-gui,admin"/> >>> ... >>> >>> In Jenkins' Configure Global Security > Access Control > Authorization > >>> Matrix-based security, the admin user has every authorization checked. >>> >>> >>> On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote: >>>> >>>> Robert is correct - when delegating you are entirely subject to >>>> authentication against the container. Jenkins handles no part of >>>> authentication in this situation. It only handles authorization via >>>> roles/groups which you sometimes have to tell the container to map. For >>>> example, you have a user scott defined in tomcat-users.xml. scott is a >>>> member of admin role (also defined in tomcat-users.xml). You should have no >>>> problems authenticating scott against the container trouble is telling the >>>> container that it's 'admin' role means the same 'admin' group in the >>>> jenkins app deployed in it. Until you do that scott cannot log into >>>> jenkins. >>>> >>>> It has been a while since I dealt with tomcat. In weblogic, for >>>> example, you would pick the combination deployment descriptors and >>>> container security policy then create either per-app or global role to >>>> group mappings. I am sure there is some sort of tomcat equivalent. Tomcat >>>> may just do this auto-magically. In fact, according to [1] it looks like it >>>> may 'just work' with only what is in tomcat-users.xml. >>>> >>>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Tomcat >>>> On Jun 3, 2014 3:52 AM, "Sandell, Robert" <robert....@sonymobile.com> >>>> wrote: >>>> >>>>> Jenkins has a servlet filter [1] that last time I checked accepts http >>>>> basic auth. But I'm not sure how/if this works when delegating to the >>>>> servlet container, you'd probably need to authenticate the way the >>>>> container dictates in that case. >>>>> >>>>> >>>>> >>>>> [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/ >>>>> main/java/hudson/security/HudsonFilter.java >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Robert Sandell* >>>>> >>>>> Software Tools Engineer - SW Environment and Product Configuration >>>>> >>>>> Sony Mobile Communications >>>>> >>>>> >>>>> >>>>> *From:* jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com] >>>>> *On Behalf Of *Scott Cowan >>>>> *Sent:* den 2 juni 2014 21:54 >>>>> *To:* jenkin...@googlegroups.com >>>>> *Subject:* form-based auth script >>>>> >>>>> >>>>> >>>>> I've followed the "Java example with httpclient 4.1.2" section of >>>>> https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+ >>>>> clients and been able to successfully authenticate a client with a >>>>> Jenkins deployed in Winstone, but I haven't been able to do so when it's >>>>> deployed in Tomcat and access control is "Delegate to servlet container". >>>>> A GET on "http://localhost:8080/jenkins"; with user/pass in basic auth >>>>> scheme returns a "HTTP/1.1 500 Internal Server Error" with the >>>>> explanation, >>>>> "anonymous is missing the Overall/Read permission". I've enabled >>>>> "Matrix-based security" and given no permissions to Anonymous. >>>>> >>>>> I noticed the auth-method in the jenkins web.xml is FORM, whether >>>>> deployed in Winstone or Tomcat. Can a client authenticate with this >>>>> configuration? Can a client negotiate a form-based authentication some >>>>> how? Does anyone have an example script to do this? >>>>> >>>>> Thanks in advance, >>>>> Scott >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to jenkinsci-de...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to jenkinsci-de...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to jenkinsci-dev+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
