Announcement Announcement Module
Collapse
No announcement yet.
Disabling Holder-of-key profile Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Disabling Holder-of-key profile

    What do I do in order to get generated metadata like this:
    Code:
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="..."/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="..." index="1" isDefault="true"/>
    Short explained: I don't want to use HoK. I tried to remove everything related to this such as samlWebSSOHoKProcessingFilter, but then my application don't want to start.

    Another thing. It shouldn't be necessary to include the port number in the generated base URL as long as it is not used. If the base URL is https://server.com/path, the path in my generated metadata contains the port number, e.g. https://server.com:443/path.

  • #2
    BTW, here is the config for metadataGeneratorFilter:
    Code:
    <bean class="org.springframework.security.saml.metadata.MetadataGenerator">
      <property name="entityBaseURL" value="https://w3utv-ws01.uio.no#{servletContext.contextPath}/"/>
      <property name="entityId" value="https://ws01.uio.no#{servletContext.contextPath}/"/>
      <property name="bindingsSSO" value="POST,HTTP-Redirect"/>
      <property name="bindingsSLO" value="HTTP-Redirect"/>
      <property name="includeDiscovery" value="false"/>
      <property name="nameID" value="TRANSIENT,PERSISTENT"/>
    </bean>
    Please ignore that the SLO for the first example is using HTTP-Artifact. It belongs to another federation. I only want to skip the HoK.

    Comment


    • #3
      The following setting (combined with what you already have) will rid you of HoK and select HTTP-Redirect for SlO and Artifact for SSO.

      Code:
      <bean class="org.springframework.security.saml.metadata.MetadataGenerator">
          <property name="bindingsSSO" value="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
          <property name="bindingsSLO" value="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
          <property name="bindingsHoKSSO"><null/></property>
      </bean>
      I'll check that port issue later.

      Vladi

      Comment


      • #4
        BTW the other option is to use the sample application's administration UI which contains a generator with checkboxes for binding selection. Instructions on how to use metadata generated in this way are in chapter 4.3 of the manual (section Pre-configured metadata).

        Also, as it seems the values for bindings and nameIDs in the manual are not correct, but will be fixed

        Vladi

        Comment


        • #5
          I'm not able to reproduce this - setting the base URL without port generates metadata URLs without port for me. What Java version do you run this on? Are you using the latest SAML Extension version?

          Originally posted by erlendfg View Post
          Another thing. It shouldn't be necessary to include the port number in the generated base URL as long as it is not used. If the base URL is https://server.com/path, the path in my generated metadata contains the port number, e.g. https://server.com:443/path.

          Comment


          • #6
            Are you trying to reproduce this issue by using SSL (https)? I guess it occurs only by using that protocol.

            This has been the case for this tool for many years, which means, on a variety of Java versions and OSes. I will only refer to our server's Java version since that is where the app is deployed:
            java version "1.6.0_37"
            Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
            Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)
            RC 2 of the SAML Extension.

            Comment


            • #7
              Originally posted by vsch View Post
              The following setting (combined with what you already have) will rid you of HoK and select HTTP-Redirect for SlO and Artifact for SSO.
              Thanks, I finally got rid of the HoK settings.

              It seems that <bean id="hokWebSSOprofileConsumer" ...> must be configured, even though I do not use it. Should I open a ticket about this?

              And how do I remove "alias/defaultAlias" for showing up in my paths? I tried this without any luck:
              Code:
              <property name="entityAlias"><null/></property>
              Regarding the port number issue - I will investigate this further in case this is something rare which only occurs on our servers running Resin. If I can reproduce it by using my personal laptop, I will open an issue regarding this problem as well.
              Last edited by erlendfg; Feb 4th, 2013, 05:06 AM.

              Comment


              • #8
                Originally posted by erlendfg View Post
                It seems that <bean id="hokWebSSOprofileConsumer" ...> must be configured, even though I do not use it. Should I open a ticket about this?
                Yes, the bean must be present, it's simply part of the Extension and in the future will be loaded automatically by a custom tag library.

                Originally posted by erlendfg View Post
                And how do I remove "alias/defaultAlias" for showing up in my paths? I tried this without any luck:
                There is currently no way to make the alias go away completely. Is there a use-case behind it or would you just like to "beautify" the URLs? Please feel free to submit a feature request to Jira for changing this.

                Originally posted by erlendfg View Post
                Regarding the port number issue - I will investigate this further in case this is something rare which only occurs on our servers running Resin. If I can reproduce it by using my personal laptop, I will open an issue regarding this problem as well.
                I was trying to reproduce it with HTTPS (on Java 7, Tomcat). And a test case tried on Java 6 behaved the same. Please let me know if you find something new.

                Comment


                • #9
                  Originally posted by vsch View Post
                  Yes, the bean must be present, it's simply part of the Extension and in the future will be loaded automatically by a custom tag library.
                  OK, then we are aware of this.

                  There is currently no way to make the alias go away completely. Is there a use-case behind it or would you just like to "beautify" the URLs? Please feel free to submit a feature request to Jira for changing this.
                  This is not that important, I was just wondering. No need to change anything.

                  I was trying to reproduce it with HTTPS (on Java 7, Tomcat). And a test case tried on Java 6 behaved the same. Please let me know if you find something new.
                  I will create another ticket about this shortly. It is easy to reproduce this issue on any computer, so I will explain how in detail when I have time. As long as it's possible to override this path by configuration, it's not a blocker for us, but I will soon get back to this.

                  Comment


                  • #10
                    But what happens if you deploy on Tomcat using mod_jk? Our servers are running on Apache using mod_caucho as a plugin to Resin. This may be the cause - or just Resin itself. Is the metadata file generated at deployment time or is it generated when you're accessing /saml/metadata from your browser?

                    Comment


                    • #11
                      I found a workaround by defining my own host bean. Take a look in the metadata settings how I'm able to get the host name and the context path which do not contain port numbers.

                      Code:
                      <bean name="host" class="java.net.InetAddress" factory-method="getLocalHost"/>
                      
                      <bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
                        ...
                        <property name="entityBaseURL" value="https://#{host.canonicalHostName}#{servletContext.contextPath}"/>
                        <property name="entityId" value="https://#{host.canonicalHostName}#{servletContext.contextPath}"/>
                        ...

                      Comment


                      • #12
                        Hi,

                        I presumed you were using the entityBaseURL property all along and were getting port in your metadata even in case it wasn't part of the entityBaseURL - based on the configuration you've sent earlier:

                        <bean class="org.springframework.security.saml.metadata. MetadataGenerator">
                        <property name="entityBaseURL" value="https://w3utv-ws01.uio.no#{servletContext.contextPath}/"/>
                        <property name="entityId" value="https://ws01.uio.no#{servletContext.contextPath}/"/>
                        <property name="bindingsSSO" value="POST,HTTP-Redirect"/>
                        <property name="bindingsSLO" value="HTTP-Redirect"/>
                        <property name="includeDiscovery" value="false"/>
                        <property name="nameID" value="TRANSIENT,PERSISTENT"/>
                        </bean>
                        This indeed explains the port generation issue. I'll change the software so that only non-standard ports are included during generation without entityBaseURL.

                        Vladi
                        Last edited by vsch; Feb 16th, 2013, 06:07 AM.

                        Comment


                        • #13
                          Hi Erlend,

                          Thanks for opening the Jira issue. There's a new feature available in trunk which covers your use-case - MetadataGeneratorFilter contains new property normalizeBaseUrl. Enabling it will remove default ports from the generated base url. Feature is disabled by default for backward compatibility reason.

                          Vladi

                          Comment

                          Working...
                          X