wp.jochen.hayek.name/blog-en

Tag: authentication

  • Jenkins CI: my account password did not work any more, but I found a way to fix it

    • Q: how to solve this? A: mostly by taking notes
    • Q: which security model do I use? A: “Role-Based Strategy“

    general approach:

    • fix a few bits within config.xml and another few bits within your Jenkins web GUI
    • for editing config.xml stop your Jenkins of course
    • create a new (privileged) user account, and change your main account’s password through this new privileged user account

    now in detail:

    • stop your Jenkins
    • within $JENKINS_HOME/config.xml change a few values for the time being:
    • toggle <useSecurity>true</useSecurity> to <useSecurity>false</useSecurity>
    • toggle  <disableSignup>true</disableSignup> to <disableSignup>false</disableSignup>
    • start your Jenkins again
    • sign up a new user account (next time your main account is in trouble, use this one!)
    • stop your Jenkins again
    • add another <sid>...</sid> entry for your new user account
    • …
    • toggle your security entries shown above back to their original values
    • start your Jenkins again
    • change the troubled account’s password Jenkins-wise
    • everything should be fine again

  • my Jenkins “automation” server at home uses the “Role Strategy Plugin”

    Without this plugin there wasn’t really any security, because everybody (even w/o user account) could see jobs and their build log files – and certain log files contain sensitive details.

    My Jenkins guru Nathan pointed me to this plugin.

  • there is an Jenkins automation server meant to be “for registered users only” — but everybody can inspect the build logs

    Its security setting looks like this:

    "Security Realm"=>"Jenkins’ own user database"

    My question: Is there a way to impose even more restrictions, e.g.:

    • before authentication you seen nothing

    You need the “role strategy” plugin for achieving this.

  • the JIRA REST API, how to authenticate, …

    There are certainly legion of reasons to use a REST API and also to use the JIRA REST API, I wanted to create a linear “diary” of JIRA actions.

    This is our sample JIRA issue URL:

    http://kelpie9:8081/browse/QA-31

    This is its corresponding REST URL:

    http://kelpie9:8081/rest/api/2/issue/QA-31

    Find yourself a working sample JIRA issue URL use the corresponding REST URL in your browser, save the JSON returned to a file!

    You usually want to read “pretty” / tidied JSON, so before you start reading JSON, find yourself a JSON-tidy utility:

    Usually we want to retrieve JSON from JIRA through REST URLs via the curl utility.

    CAVEAT: See my note on the cookie jar below!

    This is the “simple example”, that the page referred to above (“Basic Authentication“) shows you:

    $ curl -D- -u fred:fred -X GET
    -H "Content-Type: application/json"
    http://kelpie9:8081/rest/api/2/search?jql=assignee=fred

    If your JIRA site requires you to use “Basic Authentication”, you have to encode username:password base64-wise, and this is how to do it:

    $ echo -n fred:fred | base64

    So if you want to use “Basic Authentication” with these credentials, this is how … (using our sample REST URL):

    $ curl -D- -X GET
    -H "Authorization: Basic $(echo -n fred:fred | base64)"
    -H "Content-Type: application/json"
    "http://kelpie9:8081/rest/api/2/issue/QA-31"

    During my experiments I got locked out of the company’s Active Directory / SSO quite a few times — and I had to call the help desk in order to get my account reset. This is what JIRA tells you, once it decides you have to go through a CAPTCHA_CHALLENGE procedure, because you are behaving a little too suspicious:

    HTTP/1.1 403 Forbidden
    Server: Apache-Coyote/1.1
    X-AREQUESTID: ...
    X-Seraph-LoginReason: AUTHENTICATED_FAILED
    Set-Cookie: JSESSIONID=...; Path=/; Secure; HttpOnly
    WWW-Authenticate: OAuth realm="https%3A%2F%2Fjira.___.com"
    X-Content-Type-Options: nosniff
    X-Authentication-Denied-Reason: CAPTCHA_CHALLENGE; login-url=https://jira.___.com/login.jsp
    Content-Type: text/html;charset=UTF-8
    Content-Length: 6494
    Date: Wed, 02 Dec 2015 11:59:15 GMT

    But once you are beyond this, making use of the JIRA REST API works like a charm.

    Update: Although I certainly had not failed (“basic”) authentication, JIRA got my Active Directory / SSO account locked again and again. My new strategy:

    • 1st logon through “basic authentication” and store the cookie jar
    • further authentications (during a script run) though the cookie stored before — yes, I will supply you with examples here in the near future

    Wishlist:

    • instead of shell+curl use perl+libcurl
    • use the “epic link” to get the “epic link nice name” in order to describe the issue as “issue# + epic-link-nice-name + summary”
    • extend the tool to also deal with Atlassian Confluence