Uploaded image for project: 'SX Spring Security Extension'
  1. SX Spring Security Extension
  2. SES-108

some "getContextPath" call hide reverse proxy config

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: saml-1.0.0.RC1
    • Fix Version/s: saml-1.0.0.RC1
    • Component/s: saml
    • Labels:
      None

      Description

      Hello,

      The SES-42 give us a method to override the base URL. Unfortunately sometime URL are calculated from "getServletContext().getContextPath()" (for instance in the entry point when calculating the discoveryURL).

      getServletContext().getContextPath() can be invalid for the client side so no authentication is possible in those case.

        Activity

        Hide
        vsch Vladimir Schäfer added a comment -

        Hi,

        I'll try to elaborate a bit on this.

        The getContextPath is used in these places:

        SAMLDiscovery
        SAMLEntryPoint
        SAMLContextProvider

        • in SAMLDiscovery it is possible to include the reverse-proxy friendly address in SP metadata. I will add a possibility to define it also in ExtendedMetadata which will make it easier to customize the value.
        • in SAMLEntryPoint it is already possible to set custom discoveryURL in the ExtendedMetadata of the entity.
        • in the SAMLContextProvider the only relevant part is /alias/... and not the first part of the context. This should make it sufficiently reverse-proxy friendly.

        So the options are either setting the ExtendedMetadata with customized discovery URLs or not using IDP Discovery at all by setting HTTP request parameter "idp" or setting defaultIDP value on MetadataManager.

        I will also update the management UI so that entityBaseURL value is used to configure all places in SP metadata correctly once IDP discovery is enabled.

        Will this cover all your use-cases?

        Cheers, V.

        Show
        vsch Vladimir Schäfer added a comment - Hi, I'll try to elaborate a bit on this. The getContextPath is used in these places: SAMLDiscovery SAMLEntryPoint SAMLContextProvider in SAMLDiscovery it is possible to include the reverse-proxy friendly address in SP metadata. I will add a possibility to define it also in ExtendedMetadata which will make it easier to customize the value. in SAMLEntryPoint it is already possible to set custom discoveryURL in the ExtendedMetadata of the entity. in the SAMLContextProvider the only relevant part is /alias/... and not the first part of the context. This should make it sufficiently reverse-proxy friendly. So the options are either setting the ExtendedMetadata with customized discovery URLs or not using IDP Discovery at all by setting HTTP request parameter "idp" or setting defaultIDP value on MetadataManager. I will also update the management UI so that entityBaseURL value is used to configure all places in SP metadata correctly once IDP discovery is enabled. Will this cover all your use-cases? Cheers, V.
        Hide
        gwa GWA added a comment -

        Hello,

        I think this will cover my use case.

        Btw, in the metadataGenerator, why the "generateExtendedMetadata(ExtendedMetadata metadata)" statically set properties?

        Should we not be able to set those properties (+discoveryURL) on the generator ?

        Show
        gwa GWA added a comment - Hello, I think this will cover my use case. Btw, in the metadataGenerator, why the "generateExtendedMetadata(ExtendedMetadata metadata)" statically set properties? Should we not be able to set those properties (+discoveryURL) on the generator ?
        Hide
        vsch Vladimir Schäfer added a comment -

        Good idea. It's now possible to supply a default value for ExtendedMetadata to the MetadataGenerator. Some of the values in the generated ExtendedMetadata still get overwritten based on settings in the MetadataGenerator (encryptionKey, signingKey, entityAlias, tlsKey and local).

        So you can now supply a custom ExtendedMetadata value with pre-defined discovery URLs for both request and response endpoints.

        Show
        vsch Vladimir Schäfer added a comment - Good idea. It's now possible to supply a default value for ExtendedMetadata to the MetadataGenerator. Some of the values in the generated ExtendedMetadata still get overwritten based on settings in the MetadataGenerator (encryptionKey, signingKey, entityAlias, tlsKey and local). So you can now supply a custom ExtendedMetadata value with pre-defined discovery URLs for both request and response endpoints.

          People

          • Assignee:
            vsch Vladimir Schäfer
            Reporter:
            gwa GWA
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development