• Type: Bug
• Resolution: Won't Do
• Priority: Major
• Component/s: saml-plugin
• Labels:

  • SAML2
  • exception
  • saml
• Environment:

  Host Machine : Ubuntu Xenial (16.04) , hosted in AWS.
  Jenkins : ver. 2.89.4
  SAML Plugin : saml-1.0.5

1. jenkins_saml_stack_trace.txt

   8 kB

   2018-03-08 12:55

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

atul patel created issue - 2018-03-08 12:50

atul patel made changes - 2018-03-08 12:51

Description

Original: 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.

New: 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.

atul patel made changes - 2018-03-08 12:52

Description

Original: 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.

New: 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.

atul patel made changes - 2018-03-08 12:53

Description

Original: 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.

New: 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!

atul patel made changes - 2018-03-08 12:55

Attachment

New: jenkins_saml_stack_trace.txt [ 41770 ]

atul patel made changes - 2018-03-08 12:57

Description

Original: 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!

New: 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!

atul patel made changes - 2018-03-08 13:45

Description

Original: 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!

New: 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!

atul patel made changes - 2018-03-08 13:45

Description

Original: 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!

New: 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!

Ivan Fernandez Calvo made changes - 2018-03-08 13:51

Link

New: This issue is related to JENKINS-49532 [ JENKINS-49532 ]

Ivan Fernandez Calvo made changes - 2018-03-13 13:50

Resolution		New: Won't Do [ 10001 ]
Status	Original: Open [ 1 ]	New: Resolved [ 5 ]