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

SamlException after metadata update

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: saml-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.46.3
      SAML Plugin 0.14
    • Similar Issues:

      Description

      When trying to login, Jenkins with SAML plugin fails with

      org.pac4j.saml.exceptions.SamlException: No valid subject assertion found in response

      A full logout in Outlook as described in JENKINS-37289 doesn't help.

      The log jenkins/jenkins.log shows the following error:

      org.pac4j.saml.exceptions.SamlException: Signature is not trusted

      It turned out that the IdP metadata changed and I needed to update the document. But that was not possible, because I couldn't login.

      I had to give anonymous access to everything (adding <sid>anonymous</sid> in <assignedSIDs> for admin) to be able to change the metadata. Afterwards I had to remove all user data in jenkins/users/*.

      Although there's a workaround, the procedure is very annoying (when the IdP updates metadata frequently) and is in my opinion especially difficult for security reasons since I need to give access for everyone (temporarily).

      I would also think that JENKINS-44144 could solve the problem when the metadata is automatically downloaded frequently (or at least on error).

        Attachments

          Issue Links

            Activity

            Hide
            joppec Joppe Catsburg added a comment -

            We're having the same problems with this. We have multiple Jenkins instances that authenticate against Azure AD. Azure AD updates it's metadata quite frequently (normally every couple of weeks, but it can occur any time without warning). Every time this happens, nobody can logon to Jenkins anymore. This means a major outage of Jenkins for our many Jenkins users. 

            To 'fix' this means manually logging on to our many Jenkins servers and updating the IDP metadata in the Jenkins config.xml file. (tip: if you just paste the updated metadata in the config file and then restart Jenkins, you won't lose all your security configuration).

            It's considered best practice, if you authenticate against Azure AD, to reference the metadata by URL, instead of copy-pasting the metadata, as Azure can update the certificates at any time. It's really a big problem for us that the SAML plugin doesn't support this.

            This issue can be resolved by implementing JENKINS-41907

            Show
            joppec Joppe Catsburg added a comment - We're having the same problems with this. We have multiple Jenkins instances that authenticate against Azure AD. Azure AD updates it's metadata quite frequently (normally every couple of weeks, but it can occur any time without warning). Every time this happens, nobody can logon to Jenkins anymore. This means a major outage of Jenkins for our many Jenkins users.  To 'fix' this means manually logging on to our many Jenkins servers and updating the IDP metadata in the Jenkins config.xml file. (tip: if you just paste the updated metadata in the config file and then restart Jenkins, you won't lose all your security configuration). It's considered best practice, if you authenticate against Azure AD, to reference the metadata by URL, instead of copy-pasting the metadata, as Azure can update the certificates at any time. It's really a big problem for us that the SAML plugin doesn't support this. This issue can be resolved by implementing JENKINS-41907 . 
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment -

            there is a workaround in 1.0.3 version you can replace the JENKINS_HOME/saml-idp-metadata.xml file

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - there is a workaround in 1.0.3 version you can replace the JENKINS_HOME/saml-idp-metadata.xml file
            Hide
            mvoss Matthias Voss added a comment -

            OK, after updating to version 1.0.3 and the mentioned workaround, everything works as expected.

            This is a large step forward, as I now only need to download the metadata from IdP, remove the String "<?xml version="1.0" encoding="utf-8"?>" at the beginning and save it as saml-idp.metadata.xml (remark: there's a little typo in your comment, you have to replace the second "-" with ".").

            I think, if I could just configure the Saml IdP metadata download URL and the download is automatically triggered (e.g. each day or at least when this exception occurs) and saved in the file, that would be a good solution for this problem. Catching this Exception properly (e.g. when the IdP metadata is not available anymore) could make it perfect.

            So now, the update is so much easier! But the users still complain when they see the Oooops and can't work with Jenkins anymore until I update the metadata.

            Show
            mvoss Matthias Voss added a comment - OK, after updating to version 1.0.3 and the mentioned workaround, everything works as expected. This is a large step forward, as I now only need to download the metadata from IdP, remove the String "<?xml version="1.0" encoding="utf-8"?>" at the beginning and save it as saml-idp.metadata.xml (remark: there's a little typo in your comment, you have to replace the second "-" with "."). I think, if I could just configure the Saml IdP metadata download URL and the download is automatically triggered (e.g. each day or at least when this exception occurs) and saved in the file, that would be a good solution for this problem. Catching this Exception properly (e.g. when the IdP metadata is not available anymore) could make it perfect. So now, the update is so much easier! But the users still complain when they see the Oooops and can't work with Jenkins anymore until I update the metadata.
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment -

            released 1.0.5

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - released 1.0.5
            Hide
            mvoss Matthias Voss added a comment -

            After updating the plugin to version 1.0.5 I experienced the same Ooops again. I had to grant temporary access to everyone (<sid>anonymous</sid> in <assignedSIDs> in config.xml). After that I could access and enter the metadata URL in the plugin. Finally, I removed the anonymous-sid again. Now everything works as expected. Many thanks for your work.

            Show
            mvoss Matthias Voss added a comment - After updating the plugin to version 1.0.5 I experienced the same Ooops again. I had to grant temporary access to everyone ( <sid>anonymous</sid> in <assignedSIDs> in config.xml ). After that I could access and enter the metadata URL in the plugin. Finally, I removed the anonymous-sid again. Now everything works as expected. Many thanks for your work.
            Hide
            dwatroustrinet Daniel Watrous added a comment -

            I am also running 1.0.5 and provided the IdP URL provided. I also still regularly get this error. Should I submit a new issue, since this one list listed as resolved? When it happens the user has to go to office365, logout and then revisit the Jenkins server and login again.

            Show
            dwatroustrinet Daniel Watrous added a comment - I am also running 1.0.5 and provided the IdP URL provided. I also still regularly get this error. Should I submit a new issue, since this one list listed as resolved? When it happens the user has to go to office365, logout and then revisit the Jenkins server and login again.
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment -

            Daniel Watrous Open a new one, please attach the log when the issue is exposed with the loggers activated, also you can take a look at troubleshooting guide in the Azure section you have son setting to activate that resolve the issue, finally I wonder the Entry Id type that you have in your IdP Metadata we are tracking a similar issue with Azure on https://issues.jenkins-ci.org/browse/JENKINS-48030 case see the latest 10 comments.

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - Daniel Watrous Open a new one, please attach the log when the issue is exposed with the loggers activated, also you can take a look at troubleshooting guide in the Azure section you have son setting to activate that resolve the issue, finally I wonder the Entry Id type that you have in your IdP Metadata we are tracking a similar issue with Azure on https://issues.jenkins-ci.org/browse/JENKINS-48030 case see the latest 10 comments.

              People

              Assignee:
              ifernandezcalvo Ivan Fernandez Calvo
              Reporter:
              mvoss Matthias Voss
              Votes:
              5 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: