Announcement Announcement Module
No announcement yet.
SAMLContextProviderImpl has private methods instead of protected Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • SAMLContextProviderImpl has private methods instead of protected

    I am working on enhancing my SaaS-based web app to support sso; and I'm using spring-security-saml to do so. I have it all integrated with my web app, such that the IDP metadata is configured in the security-context.xml file, per the samples.

    However, since my app is SaaS-based, the IDP metadata needs to be configured and determined during run-time, not at startup-time. So, the metadata is not directly in the security-context.xml; instead, it is pulled from a database based on my tenant data.

    During run-time, the tenant is determined based on an http request parameter; and therefore, the IDP to connect to is determined once the tenant is discovered from the http request.

    I've got the dynamic metadata working, by creating my own MetadataManager that extends CachingMetadataManager.

    Now, I'm working on getting the http request parameter to determine the tenant and then getting the correct IDP to connect to, during the spring-security-saml authentication filter chain process. I think I've figured out the correct place to hook into that chain. The SAMLContextProviderImpl.populatePeerEntityId is the method that gets the IDP from the MetadataManager; so I am using my own class that extends the SAMLContextProviderImpl, overriding the getLocalAndPeerEntity method, which has the HttpServletRequest passed in as an argument (from which I can then get the http request param for the tenant), and then which calls the populatePeerEntityId method, which I then override and customize to get the correct IDP from my own MetadataManager, using the tenant http request param value.

    The problem is that when I extend SAMLContextProviderImpl and override the getLocalAndPeerEntity method, it is invoking some other methods that are marked as private in the parent class. Namely, those methods are: populateGenericContext, populateLocalContext, populateLocalEntity, and populatePeerContext.

    Why are those methods marked private? Shouldn't they be protected, so I can more easily extend/customize this class?

    Also, has anyone else already done what I'm trying to do and might have a better way of doing this?

  • #2
    We faced the same problem, you basically have two options:

    1. Fork the code and make those methods protected, potentially submitting a patch to Vldimir
    2. Proxy the SAMLMessageContext using AOP and make the runtime changes there. SAMLMessageContext is the "bucket" that gets passed around the SAML code so you can do a lot if you proxy this.

    In the end we went with option 2 because we were able to make some additional enhancements without having to significantly refactor the core spring-saml code. Good luck!


    • #3
      CachingMetadataManager and SAMLContextProvider are the intended extension places for enabling these kinds of use-cases. The initial reason to keep some of the SAMLContextProviderImpl methods private was to make sure that the essential parts of the context get always populated and make it possible to make future changes without danger of breaking extensions. But, as it's causing issues I don't see much reason why not to make all the methods protected.

      Vladimír Schäfer


      • #4
        Available in trunk and upcoming RC2, tracked under