Details

    • Similar Issues:
    • Released As:
      saml-1.1.5

      Description

      The strings SP_METADATA_FILE_NAME and IDP_METADATA_FILE_NAME have hardcoded /'s in them which means getIDPMetadataFilePath() and getSPMetadataFilePath() do not return valid paths in windows.

        Attachments

          Issue Links

            Activity

            Hide
            willwh William Hetherington added a comment -

            This change has no tests, I am replacing a "/" in a string in favour of File.separator, so that this will work on windows.

            Show
            willwh William Hetherington added a comment - This change has no tests, I am replacing a "/" in a string in favour of File.separator, so that this will work on windows.
            Hide
            willwh William Hetherington added a comment - - edited

            Hi Ivan,

            I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows.

            public HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) {
                return new SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();     
            }

            I think that the path for the metadata that is being passed is incorrect.
             
            Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:
             

            [id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
            [id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
            [id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users
            [id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml
            [id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins
            [id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml
            [id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.

             

            My guess is, the path being passed is C:\Jenkins\saml-sp-metadata.xml - and this is ultimately causing pac4j to not find the saml-sp-metadata.xml: (Windows paths usually want escaped \'s ?) 

            https://github.com/jenkinsci/saml-plugin/blob/master/src/main/java/org/jenkinsci/plugins/saml/SamlSPMetadataWrapper.java#L42-L44

             

            Based on this failing: https://github.com/pac4j/pac4j/blob/f82b377690f400f518145a4d543acb187d4dd4ac/pac4j-saml/src/main/java/org/pac4j/saml/metadata/SAML2ServiceProviderMetadataResolver.java#L134-L160

             

            Do you have any thoughts here? I will try to update this issue as soon as I have Idp config for testing, some time next week.

             

            Show
            willwh William Hetherington added a comment - - edited Hi Ivan, I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows. public  HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) { return   new  SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();      } I think that the path for the metadata that is being passed is incorrect.   Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:   [id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API [id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API [id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users [id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml [id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins [id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml [id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.   My guess is, the path being passed is C:\Jenkins\saml-sp-metadata.xml - and this is ultimately causing pac4j to not find the saml-sp-metadata.xml : (Windows paths usually want escaped \'s ?)  https://github.com/jenkinsci/saml-plugin/blob/master/src/main/java/org/jenkinsci/plugins/saml/SamlSPMetadataWrapper.java#L42-L44   Based on this failing:  https://github.com/pac4j/pac4j/blob/f82b377690f400f518145a4d543acb187d4dd4ac/pac4j-saml/src/main/java/org/pac4j/saml/metadata/SAML2ServiceProviderMetadataResolver.java#L134-L160   Do you have any thoughts here? I will try to update this issue as soon as I have Idp config for testing, some time next week.  
            Hide
            ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited

            this is a warning not an error, it is normal, I cannot rid of it because it is in the pac4j library. Your problem should be other, enable verbosely log (https://github.com/jenkinsci/saml-plugin/blob/master/doc/TROUBLESHOOTING.md) and see if the SAML request is sent, if so, the redirection has to be done by the browser. To avoid mix this issue with you another issue, please open a thread on the google groups with the details of the login process (what steps are done in the verbose log), I would help you there. I will close this issue.

            Show
            ifernandezcalvo Ivan Fernandez Calvo added a comment - - edited this is a warning not an error, it is normal, I cannot rid of it because it is in the pac4j library. Your problem should be other, enable verbosely log ( https://github.com/jenkinsci/saml-plugin/blob/master/doc/TROUBLESHOOTING.md ) and see if the SAML request is sent, if so, the redirection has to be done by the browser. To avoid mix this issue with you another issue, please open a thread on the google groups with the details of the login process (what steps are done in the verbose log), I would help you there. I will close this issue.

              People

              • Assignee:
                willwh William Hetherington
                Reporter:
                willwh William Hetherington
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: