Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-50016

Contents of saml-sp-metadata.xml changes whenever jenkins service is restarted locking users out

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Do
    • Component/s: saml-plugin
    • Labels:
    • Environment:
      Host Machine : Ubuntu Xenial (16.04) , hosted in AWS.
      Jenkins : ver. 2.89.4
      SAML Plugin : saml-1.0.5
    • Similar Issues:

      Description

      Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

      A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

      Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;

      org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder

      Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

      Not sure if its because the contents of JENKINS_HOME/saml-sp-metadata.xml  is the root cause for the lockout.

      Possible Workarounds;

      1. Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works without further hacking. This worked and got me working again - but not an ideal workaround where IT team is subcontracted out in a different time zone.
      2. Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work, this would be least disruptive and quicker turn around.
      3. Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!

       

        Attachments

          Issue Links

            Activity

            atulkpatel atul patel created issue -
            atulkpatel atul patel made changes -
            Field Original Value New Value
            Description Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Possible Workarounds;
            # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works.

            # Attempt to restore a backup copy of JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
            Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works.
             # Attempt to restore a backup copy of JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
            atulkpatel atul patel made changes -
            Description Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works.
             # Attempt to restore a backup copy of JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
            Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works without further hacking.
             # Attempt to restore a backup copy of JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
            atulkpatel atul patel made changes -
            Description Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works without further hacking.
             # Attempt to restore a backup copy of JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
            Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works without further hacking.
             # Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
             # Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!

             
            atulkpatel atul patel made changes -
            Attachment jenkins_saml_stack_trace.txt [ 41770 ]
            atulkpatel atul patel made changes -
            Description Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works without further hacking.
             # Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
             # Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!

             
            Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Not sure if its because the contents of JENKINS_HOME/saml-sp-metadata.xml  is causing the lockout.

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works without further hacking.
             # Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
             # Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!

             
            atulkpatel atul patel made changes -
            Description Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Not sure if its because the contents of JENKINS_HOME/saml-sp-metadata.xml  is causing the lockout.

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - need to confirm this works without further hacking.
             # Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work.
             # Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!

             
            Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Not sure if its because the contents of JENKINS_HOME/saml-sp-metadata.xml  is causing the lockout.

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - -need to confirm this works without further hacking-. This worked and got me working again - but not an ideal workaround where IT team is subcontracted out in a different time zone.
             # Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work, this would be least disruptive and quicker turn around.
             # Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!

             
            atulkpatel atul patel made changes -
            Description Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Not sure if its because the contents of JENKINS_HOME/saml-sp-metadata.xml  is causing the lockout.

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - -need to confirm this works without further hacking-. This worked and got me working again - but not an ideal workaround where IT team is subcontracted out in a different time zone.
             # Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work, this would be least disruptive and quicker turn around.
             # Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!

             
            Jenkins setup was configured to talk to AD via SAML,  Users could login via SAML and Jenkins could show AD groups associated with users. All working as expected.

            A plugin update was available which required Jenkins to be restarted. Upon initiating the plugin update and requesting Jekins to restart resulted in users being locked out with an OOPS message.

            Restarting Jenkins service either via the WebUI or manually from the backend (systemctl restart) appears to re-generate the contents (x509Certificate data) in JENKINS_HOME/saml-sp-metadata.xml . Thus user is locked out with the following OOPs being reported;
            {code:java}
            org.pac4j.saml.exceptions.SAMLException: Authentication response is not success ; actual urn:oasis:names:tc:SAML:2.0:status:Responder{code}
            Not sure if regenerating the contents of saml-sp-metadata.xml is expected behaviour by design for perhaps security reasons?  

            Not sure if its because the contents of JENKINS_HOME/saml-sp-metadata.xml  is the root cause for the lockout.

            Possible Workarounds;
             # Send new JENKINS_HOME/saml-sp-metadata.xml  file to IT team to import into AD server - -need to confirm this works without further hacking-. This worked and got me working again - but not an ideal workaround where IT team is subcontracted out in a different time zone.
             # Attempt to restore a backup copy of $JENKINS_HOME/saml-sp-metadata.xml  - attempted but this didn't work, this would be least disruptive and quicker turn around.
             # Hack $JENKINS_HOME/config.xml to disable SAML plugin to gain access - this worked, but a bit of a pain!

             
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Link This issue is related to JENKINS-49532 [ JENKINS-49532 ]
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Resolution Won't Do [ 10001 ]
            Status Open [ 1 ] Resolved [ 5 ]

              People

              Assignee:
              ifernandezcalvo Ivan Fernandez Calvo
              Reporter:
              atulkpatel atul patel
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: