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

SAML Azure AD exception

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Jenkins: 2.76
      Jenkins-SAML: 1.0.4

      Our users are getting this exception every morning:
      org.pac4j.saml.exceptions.SAMLException: No valid subject assertion found in response at stacktrace

        Attachments

          Issue Links

            Activity

            jangazda Jan Gazda created issue -
            jangazda Jan Gazda made changes -
            Field Original Value New Value
            Description Our users are getting this exception every morning:
            org.pac4j.saml.exceptions.SAMLException: No valid subject assertion found in response at [^stacktrace]
            Jenkins: 2.76
            Jenkins-SAML: 1.0.4

            Our users are getting this exception every morning:
             org.pac4j.saml.exceptions.SAMLException: No valid subject assertion found in response at [^stacktrace]
            Hide
            jangazda Jan Gazda added a comment -

            Any progress in this? it's really annoying :/

            Can I help somehow?

            Show
            jangazda Jan Gazda added a comment - Any progress in this? it's really annoying :/ Can I help somehow?
            Hide
            shawnparslow Shawn Parslow added a comment -

            My organization is seeing this behavior also, we are using Azure AD and SAML authentication with several servers/services and Jenkins is the only one that seems to be giving a problem.  Everything works fine once configured but upon logging in (via SAML) and then leaving the system for some period of time (like overnight) and trying to log in again we are met with the same error.  The only way to correct it seems to be to go to Azure and sign out of the user name (or clear all cache/cookies/etc) and then hit the Jenkins sign-in again (and re-auth to Azure AD).  Its as if the azure signin is expiring but we dont notice this issue with any other systems.  We looked at increasing the "Maximum Authentication Lifetime" in the SAML settings in Jenkins but it didnt change anything (also worth noting, the SAML finish login error is "No valid subject assertion found in response" and not one related to auth lifetime like "Authentication issue instant is too old or in the future").  Following...

            Show
            shawnparslow Shawn Parslow added a comment - My organization is seeing this behavior also, we are using Azure AD and SAML authentication with several servers/services and Jenkins is the only one that seems to be giving a problem.  Everything works fine once configured but upon logging in (via SAML) and then leaving the system for some period of time (like overnight) and trying to log in again we are met with the same error.  The only way to correct it seems to be to go to Azure and sign out of the user name (or clear all cache/cookies/etc) and then hit the Jenkins sign-in again (and re-auth to Azure AD).  Its as if the azure signin is expiring but we dont notice this issue with any other systems.  We looked at increasing the "Maximum Authentication Lifetime" in the SAML settings in Jenkins but it didnt change anything (also worth noting, the SAML finish login error is "No valid subject assertion found in response" and not one related to auth lifetime like "Authentication issue instant is too old or in the future").  Following...
            Hide
            shawnparslow Shawn Parslow added a comment -

            So I am not clear if this is a solution but I wanted to share (possibly get feedback).  When SAML authentication to Azure AD occurs there are 2 tokens that come down...the Access Token and the Refresh Token.  The max lifetime of the Access Token in Azure AD seems to be 24 hours where the refresh token can live for a maximum of 14 days (if the access token expires the refresh token is used to try to obtain a new access token).  I am suspicious of the Jenkins setting in Configure Global Security > SAML Identity Provider Settings > Maximum Authentication Lifetime.  The default here is the equivalent of 24 hours (86400 in seconds).  This would seem to be ok with the Access Token but perhaps its interfering with the lifecycle of the Refresh Token.  In my system I have tested upping this to 1209600 (which is 14 days in seconds/the max lifetime of the Refresh Token).  Its worth noting that values can be tweaked in Azure also but it seems its via an AzureADPreview preview module to Get/Set AzureADPolicy.

            Show
            shawnparslow Shawn Parslow added a comment - So I am not clear if this is a solution but I wanted to share (possibly get feedback).  When SAML authentication to Azure AD occurs there are 2 tokens that come down...the Access Token and the Refresh Token.  The max lifetime of the Access Token in Azure AD seems to be 24 hours where the refresh token can live for a maximum of 14 days (if the access token expires the refresh token is used to try to obtain a new access token).  I am suspicious of the Jenkins setting in Configure Global Security > SAML Identity Provider Settings > Maximum Authentication Lifetime.  The default here is the equivalent of 24 hours (86400 in seconds).  This would seem to be ok with the Access Token but perhaps its interfering with the lifecycle of the Refresh Token.  In my system I have tested upping this to 1209600 (which is 14 days in seconds/the max lifetime of the Refresh Token).  Its worth noting that values can be tweaked in Azure also but it seems its via an AzureADPreview preview module to Get/Set AzureADPolicy.
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment -

            nice feedback, probably I have to add a note about Azure AD and these tokens live cycle, probably enable the advanced "force authentication" setting is another workaround.

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - nice feedback, probably I have to add a note about Azure AD and these tokens live cycle, probably enable the advanced "force authentication" setting is another workaround.
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Remote Link This issue links to "PR (Web Link)" [ 19337 ]
            Hide
            jangazda Jan Gazda added a comment -

            Thanks I will try "force authentication" within our org.

            Show
            jangazda Jan Gazda added a comment - Thanks I will try "force authentication" within our org.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Ivan Fernandez Calvo
            Path:
            README.md
            pom.xml
            src/main/java/org/jenkinsci/plugins/saml/IdpMetadataConfiguration.java
            src/main/java/org/jenkinsci/plugins/saml/OpenSAMLWrapper.java
            src/main/java/org/jenkinsci/plugins/saml/SamlAdvancedConfiguration.java
            src/main/java/org/jenkinsci/plugins/saml/SamlEncryptionData.java
            src/main/java/org/jenkinsci/plugins/saml/SamlLogoutAction.java
            src/main/java/org/jenkinsci/plugins/saml/SamlPluginConfig.java
            src/main/java/org/jenkinsci/plugins/saml/SamlSecurityRealm.java
            src/main/java/org/jenkinsci/plugins/saml/UpdateMetadataFromURLPeriodicWork.java
            src/main/resources/org/jenkinsci/plugins/saml/IdpMetadataConfiguration/config.jelly
            src/main/resources/org/jenkinsci/plugins/saml/SamlAdvancedConfiguration/config.jelly
            src/main/resources/org/jenkinsci/plugins/saml/SamlEncryptionData/config.jelly
            src/main/resources/org/jenkinsci/plugins/saml/SamlLogoutAction/index.jelly
            src/main/resources/org/jenkinsci/plugins/saml/SamlSecurityRealm/config.jelly
            src/main/webapp/help/metadataPeriod.html
            src/main/webapp/help/metadataURL.html
            src/test/java/org/jenkinsci/plugins/saml/OpenSamlWrapperTest.java
            src/test/java/org/jenkinsci/plugins/saml/SamlFormValidationsTest.java
            src/test/java/org/jenkinsci/plugins/saml/SamlSecurityRealmTest.java
            http://jenkins-ci.org/commit/saml-plugin/d3c1f8d30966766f864ae2b0178bae89b5e94cc0
            Log:
            JENKINS-41907 obtain IdP Metadata from URL (#39)

            • feature to get the IdP Metadata from an URL
            • fix tests
            • AsyncAperiodicWork to update the IdP Metadata
            • support get ipd metadata from URL
            • run after start
              process the XML from the URL and save it without the XML declaration
            • add XML declaration to IdP metadata
            • fix test
              add base acceptan test
            • exclusion on acceptance-test-harness to be able to package
            • changes before merge
            • merge with master
            • finally the form works and do not have extrange side efects, I hate jelly
            • form validation methods refactor
            • validate that XML and URL are not blank
            • fix test
            • cleanup
            • JENKINS-47880 Navigating to /securityRealm/finishLogin manually shows an odd error
            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ivan Fernandez Calvo Path: README.md pom.xml src/main/java/org/jenkinsci/plugins/saml/IdpMetadataConfiguration.java src/main/java/org/jenkinsci/plugins/saml/OpenSAMLWrapper.java src/main/java/org/jenkinsci/plugins/saml/SamlAdvancedConfiguration.java src/main/java/org/jenkinsci/plugins/saml/SamlEncryptionData.java src/main/java/org/jenkinsci/plugins/saml/SamlLogoutAction.java src/main/java/org/jenkinsci/plugins/saml/SamlPluginConfig.java src/main/java/org/jenkinsci/plugins/saml/SamlSecurityRealm.java src/main/java/org/jenkinsci/plugins/saml/UpdateMetadataFromURLPeriodicWork.java src/main/resources/org/jenkinsci/plugins/saml/IdpMetadataConfiguration/config.jelly src/main/resources/org/jenkinsci/plugins/saml/SamlAdvancedConfiguration/config.jelly src/main/resources/org/jenkinsci/plugins/saml/SamlEncryptionData/config.jelly src/main/resources/org/jenkinsci/plugins/saml/SamlLogoutAction/index.jelly src/main/resources/org/jenkinsci/plugins/saml/SamlSecurityRealm/config.jelly src/main/webapp/help/metadataPeriod.html src/main/webapp/help/metadataURL.html src/test/java/org/jenkinsci/plugins/saml/OpenSamlWrapperTest.java src/test/java/org/jenkinsci/plugins/saml/SamlFormValidationsTest.java src/test/java/org/jenkinsci/plugins/saml/SamlSecurityRealmTest.java http://jenkins-ci.org/commit/saml-plugin/d3c1f8d30966766f864ae2b0178bae89b5e94cc0 Log: JENKINS-41907 obtain IdP Metadata from URL (#39) feature to get the IdP Metadata from an URL fix tests AsyncAperiodicWork to update the IdP Metadata support get ipd metadata from URL run after start process the XML from the URL and save it without the XML declaration add XML declaration to IdP metadata fix test add base acceptan test exclusion on acceptance-test-harness to be able to package changes before merge merge with master finally the form works and do not have extrange side efects, I hate jelly form validation methods refactor validate that XML and URL are not blank fix test cleanup JENKINS-47880 Navigating to /securityRealm/finishLogin manually shows an odd error JENKINS-48030 SAML Azure AD exception JENKINS-46063 do not allow blank passwords
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment -

            release 1.0.5

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - release 1.0.5
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            Hide
            jamiecon Jamie added a comment -

            Just wanted to add my thanks for the hard work that went in to this release. We are using Azure AD and Jenkins and have been experiencing this error. I have installed 1.0.5, added the URL to download metadata with refresh every 24 hours, and enabled Force Authentication - we will monitor and report back.

            Show
            jamiecon Jamie added a comment - Just wanted to add my thanks for the hard work that went in to this release. We are using Azure AD and Jenkins and have been experiencing this error. I have installed 1.0.5, added the URL to download metadata with refresh every 24 hours, and enabled Force Authentication - we will monitor and report back.
            Hide
            jangazda Jan Gazda added a comment - - edited

            Very good, thank you!
            I will give it a try.

            Jamie where can I find metadata url in Azure AD please? I'm alway using the xml file downloaded from Enterprise App.
            Thank you

            Show
            jangazda Jan Gazda added a comment - - edited Very good, thank you! I will give it a try. Jamie where can I find metadata url in Azure AD please? I'm alway using the xml file downloaded from Enterprise App. Thank you
            Hide
            jamiecon Jamie added a comment -

            Jan Gazda you can find the URL in the Azure Portal. Select Azure Active Directory > App Registrations, then click the Endpoints button in the top bar. You want the first URL on the list which is titled Federation Metadata Document.

            Hope this helps

            Show
            jamiecon Jamie added a comment - Jan Gazda you can find the URL in the Azure Portal. Select Azure Active Directory > App Registrations, then click the Endpoints button in the top bar. You want the first URL on the list which is titled Federation Metadata Document. Hope this helps
            Hide
            jamiecon Jamie added a comment -

            I have been doing some testing and have the following results:

            With the SAML metadata URL download feature in use and no other changes from the default settings, I continued to see the error which begins 'org.pac4j.saml.exceptions.SAMLException: No valid subject assertion found in response at' every 24 hours.

            If I enable the 'Force Authentication' checkbox in advanced settings, I am prompted to log to Azure every time I open the Jenkins URL. However occasionally I see an error while logging in to Azure with the following details:

            Sorry, but we’re having trouble with signing you in.
            We've received a bad request.
            Additional technical information:
            Correlation ID: 5d3a3569-1101-412e-ac60-5d09d8a3d6d1
            Timestamp: 2018-01-30 07:39:57Z
            AADSTS165000: Invalid Request: The request tokens do not match the user context. One or more of the user context values (cookies; form fields; headers) were incorrect or invalid, these values should not be copied between requests or user sessions; always maintain the ALL of the supplied values across a complete single user flow. Failure Reasons:[Token is invalid;]

             

            Unfortunately for me it seems the 1.0.5 release doesn't fix this bug. Has anyone else had success with particular settings?

            Thanks in advance

             

             

             

            Show
            jamiecon Jamie added a comment - I have been doing some testing and have the following results: With the SAML metadata URL download feature in use and no other changes from the default settings, I continued to see the error which begins 'org.pac4j.saml.exceptions.SAMLException: No valid subject assertion found in response at' every 24 hours. If I enable the 'Force Authentication' checkbox in advanced settings, I am prompted to log to Azure every time I open the Jenkins URL. However occasionally I see an error while logging in to Azure with the following details: Sorry, but we’re having trouble with signing you in. We've received a bad request. Additional technical information: Correlation ID: 5d3a3569-1101-412e-ac60-5d09d8a3d6d1 Timestamp: 2018-01-30 07:39:57Z AADSTS165000: Invalid Request: The request tokens do not match the user context. One or more of the user context values (cookies; form fields; headers) were incorrect or invalid, these values should not be copied between requests or user sessions; always maintain the ALL of the supplied values across a complete single user flow. Failure Reasons: [Token is invalid;]   Unfortunately for me it seems the 1.0.5 release doesn't fix this bug. Has anyone else had success with particular settings? Thanks in advance      
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited

            Could you check if in the JENKINS_HOME/saml-idp-metadata.xml if you have the attribute validUntil in the element EntityDescriptor? and check that your Maximum Authentication Lifetime will expire before this validUntil date and your Advanced Configuration/Maximum Session Lifetime is also less than your Maximum Authentication Lifetime

            Advanced Configuration/Maximum Session Lifetime <= Maximum Authentication Lifetime < validUntil

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited Could you check if in the JENKINS_HOME/saml-idp-metadata.xml if you have the attribute validUntil in the element EntityDescriptor ? and check that your Maximum Authentication Lifetime will expire before this validUntil date and your Advanced Configuration/Maximum Session Lifetime is also less than your Maximum Authentication Lifetime Advanced Configuration/Maximum Session Lifetime <= Maximum Authentication Lifetime < validUntil
            Hide
            jamiecon Jamie added a comment - - edited

            Thanks for the response Ivan.

            The saml-idp-metadata.xml file does not contain the attribute validUntil on my system where you mentioned or elsewhere in the file.

            At present both the Maximum Session Lifetime and Maximum Authentication Lifetime values are set to 86400.

            Would it be helpful if I posted the entire contents of the saml-idp-metadata.xml file on my system? No idea if it contains sensitive information.

            Show
            jamiecon Jamie added a comment - - edited Thanks for the response Ivan. The saml-idp-metadata.xml file does not contain the attribute validUntil on my system where you mentioned or elsewhere in the file. At present both the Maximum Session Lifetime and Maximum Authentication Lifetime values are set to 86400. Would it be helpful if I posted the entire contents of the saml-idp-metadata.xml file on my system? No idea if it contains sensitive information.
            Hide
            walliski Kim added a comment -

            We are also experiencing problems with 1.0.5, have tried making the max auth lifetime longer, and now enabled forced login. The forced authentication makes it possible to use Jenkins, but it is a major annoyance having to log in "all the time".

            Show
            walliski Kim added a comment - We are also experiencing problems with 1.0.5, have tried making the max auth lifetime longer, and now enabled forced login. The forced authentication makes it possible to use Jenkins, but it is a major annoyance having to log in "all the time".
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited

            I am documenting how to configure Azure service to work with the plugin and there is something in the documentation about the Entry ID in the Idp Metadata XML that claim my attention there are two formats

            • entityID="https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db45/"
            • entityID="https://sts.windows.net/ {tenant}

              /"

            the first one seems that could change with the time and the second one seems to be always the same, Could you check the Entry ID type you use in your IdP Metadata XML?

            https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-federation-metadata#entity-id

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited I am documenting how to configure Azure service to work with the plugin and there is something in the documentation about the Entry ID in the Idp Metadata XML that claim my attention there are two formats entityID="https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db45/" entityID="https://sts.windows.net/ {tenant} /" the first one seems that could change with the time and the second one seems to be always the same, Could you check the Entry ID type you use in your IdP Metadata XML? https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-federation-metadata#entity-id
            Hide
            shawnparslow Shawn Parslow added a comment -

            My configuration uses the Azure GUID in the entityID:
            entityID="https://sts.windows.net/12345678-1234-1234-1234-123456abcdef/" 

            FYI, this GUID represents the Directory ID of your Azure Active Directory in your subscription that you are authenticating against (you might want to scrub it from your comment).

             

            Show
            shawnparslow Shawn Parslow added a comment - My configuration uses the Azure GUID in the entityID: entityID="https://sts.windows.net/12345678-1234-1234-1234-123456abcdef/"  FYI, this GUID represents the Directory ID of your Azure Active Directory in your subscription that you are authenticating against (you might want to scrub it from your comment).  
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Link This issue is related to JENKINS-49923 [ JENKINS-49923 ]
            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited Shawn Parslow both are C&P from https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-federation-metadata#entity-id so they should be not valid values.
            Hide
            jamiecon Jamie added a comment -

            Ivan Fernandez Calvo My configuration also uses a GUID, in the first format style.

            Not my area but isn't this feature something to do with if you are, say, building a hosted application which allows multiple Azure AD users to utilise it?

            Show
            jamiecon Jamie added a comment - Ivan Fernandez Calvo My configuration also uses a GUID, in the first format style. Not my area but isn't this feature something to do with if you are, say, building a hosted application which allows multiple Azure AD users to utilise it?
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment -

            I do not have all the context but the first is tenant-specific and the second one is tenant-independent, I am not sure if this token can change or not in the first choice.

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - I do not have all the context but the first is tenant-specific and the second one is tenant-independent, I am not sure if this token can change or not in the first choice.
            Hide
            jamiecon Jamie added a comment -

            Ivan Fernandez Calvo I see. I have made a note of the value for my system and I will check back every few days to see if it has changed. I'll report back in a week or so I guess?

            Show
            jamiecon Jamie added a comment - Ivan Fernandez Calvo I see. I have made a note of the value for my system and I will check back every few days to see if it has changed. I'll report back in a week or so I guess?
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Link This issue is related to JENKINS-50004 [ JENKINS-50004 ]
            ifernandezcalvo Ivan Fernandez Calvo made changes -
            Link This issue is related to JENKINS-44992 [ JENKINS-44992 ]
            Hide
            jamiecon Jamie added a comment -

            I have just rechecked the value and it is the same now as it was on the 6th of this month.

            Hope this helps

            Show
            jamiecon Jamie added a comment - I have just rechecked the value and it is the same now as it was on the 6th of this month. Hope this helps

              People

              Assignee:
              ifernandezcalvo Ivan Fernandez Calvo
              Reporter:
              jangazda Jan Gazda
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: