Santuario
  1. Santuario
  2. SANTUARIO-157

Allow to pass a custom config.xml resource path via Init.init() method

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Java
    • Security Level: Public (Public issues, viewable by everyone)
    • Labels:
      None
    • Environment:
      Operating System: Linux
      Platform: PC

      Description

      If xmlsec is used in an container env, every webapp can now use its own config and
      and dont rely on the global one.

      Attached is a patch which is tested against xmlsec trunk.

      Feel free to include/modify/extend/decline the attached patch

        Activity

        Hide
        sean.mullan added a comment -

        (In reply to comment #6)
        > (In reply to comment #5)
        > > (In reply to comment #4)
        > > > Sean,
        > > >
        > > > Yes, we always pass the custom config via
        > > > org.apache.xml.security.resource.config
        > > > property. The problem with this solution is the inability to specify different
        > > > configs for e.g. different webservices in the same Container/VM.
        > >
        > > Ok, but I believe that requires changes to support multiple configurations in
        > > the same VM. Right now, there is only one configuration per VM.
        > > So this patch doesn't solve that problem.
        >
        > I think it does but perhaps I didn't express myself correctly:
        > What I meant is when I have multiple web-apps deployed (e.g webservices) and
        > every deployment has it's own copy of xmlsec.jar then the
        > org.apache.xml.security.Init class will be loaded multiple times, once per
        > webapp beause of the class loader hirarchy. No?

        Ok, I see now. Yes, I believe you're right.

        Let me think about this some more and get back to you.

        Show
        sean.mullan added a comment - (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Sean, > > > > > > Yes, we always pass the custom config via > > > org.apache.xml.security.resource.config > > > property. The problem with this solution is the inability to specify different > > > configs for e.g. different webservices in the same Container/VM. > > > > Ok, but I believe that requires changes to support multiple configurations in > > the same VM. Right now, there is only one configuration per VM. > > So this patch doesn't solve that problem. > > I think it does but perhaps I didn't express myself correctly: > What I meant is when I have multiple web-apps deployed (e.g webservices) and > every deployment has it's own copy of xmlsec.jar then the > org.apache.xml.security.Init class will be loaded multiple times, once per > webapp beause of the class loader hirarchy. No? Ok, I see now. Yes, I believe you're right. Let me think about this some more and get back to you.
        Hide
        Marc Giger added a comment -

        (In reply to comment #5)
        > (In reply to comment #4)
        > > Sean,
        > >
        > > Yes, we always pass the custom config via
        > > org.apache.xml.security.resource.config
        > > property. The problem with this solution is the inability to specify different
        > > configs for e.g. different webservices in the same Container/VM.
        >
        > Ok, but I believe that requires changes to support multiple configurations in
        > the same VM. Right now, there is only one configuration per VM.
        > So this patch doesn't solve that problem.

        I think it does but perhaps I didn't express myself correctly:
        What I meant is when I have multiple web-apps deployed (e.g webservices) and every deployment has it's own copy of xmlsec.jar then the org.apache.xml.security.Init class will be loaded multiple times, once per webapp beause of the class loader hirarchy. No?

        >
        > > On the other hand I see your point with the security concern.
        > > Perhaps we can add a custom Permission class to check against current active
        > > SecurityManager/SecurityPolicy if we are allowed to set the config? Altough
        > > I've never done this.
        > >
        > > What do you think?
        >
        > I think if you added a per-App/container configuration such that it wouldn't
        > affect any other threads in the same VM then you may not need to protect it
        > with a permission.

        Show
        Marc Giger added a comment - (In reply to comment #5) > (In reply to comment #4) > > Sean, > > > > Yes, we always pass the custom config via > > org.apache.xml.security.resource.config > > property. The problem with this solution is the inability to specify different > > configs for e.g. different webservices in the same Container/VM. > > Ok, but I believe that requires changes to support multiple configurations in > the same VM. Right now, there is only one configuration per VM. > So this patch doesn't solve that problem. I think it does but perhaps I didn't express myself correctly: What I meant is when I have multiple web-apps deployed (e.g webservices) and every deployment has it's own copy of xmlsec.jar then the org.apache.xml.security.Init class will be loaded multiple times, once per webapp beause of the class loader hirarchy. No? > > > On the other hand I see your point with the security concern. > > Perhaps we can add a custom Permission class to check against current active > > SecurityManager/SecurityPolicy if we are allowed to set the config? Altough > > I've never done this. > > > > What do you think? > > I think if you added a per-App/container configuration such that it wouldn't > affect any other threads in the same VM then you may not need to protect it > with a permission.
        Hide
        sean.mullan added a comment -

        (In reply to comment #4)
        > Sean,
        >
        > Yes, we always pass the custom config via
        > org.apache.xml.security.resource.config
        > property. The problem with this solution is the inability to specify different
        > configs for e.g. different webservices in the same Container/VM.

        Ok, but I believe that requires changes to support multiple configurations in the same VM. Right now, there is only one configuration per VM.
        So this patch doesn't solve that problem.

        > On the other hand I see your point with the security concern.
        > Perhaps we can add a custom Permission class to check against current active
        > SecurityManager/SecurityPolicy if we are allowed to set the config? Altough
        > I've never done this.
        >
        > What do you think?

        I think if you added a per-App/container configuration such that it wouldn't affect any other threads in the same VM then you may not need to protect it with a permission.

        Show
        sean.mullan added a comment - (In reply to comment #4) > Sean, > > Yes, we always pass the custom config via > org.apache.xml.security.resource.config > property. The problem with this solution is the inability to specify different > configs for e.g. different webservices in the same Container/VM. Ok, but I believe that requires changes to support multiple configurations in the same VM. Right now, there is only one configuration per VM. So this patch doesn't solve that problem. > On the other hand I see your point with the security concern. > Perhaps we can add a custom Permission class to check against current active > SecurityManager/SecurityPolicy if we are allowed to set the config? Altough > I've never done this. > > What do you think? I think if you added a per-App/container configuration such that it wouldn't affect any other threads in the same VM then you may not need to protect it with a permission.
        Hide
        Marc Giger added a comment -

        Sean,

        Yes, we always pass the custom config via org.apache.xml.security.resource.config
        property. The problem with this solution is the inability to specify different configs for e.g. different webservices in the same Container/VM.

        On the other hand I see your point with the security concern.
        Perhaps we can add a custom Permission class to check against current active SecurityManager/SecurityPolicy if we are allowed to set the config? Altough I've never done this.

        What do you think?

        Marc

        Show
        Marc Giger added a comment - Sean, Yes, we always pass the custom config via org.apache.xml.security.resource.config property. The problem with this solution is the inability to specify different configs for e.g. different webservices in the same Container/VM. On the other hand I see your point with the security concern. Perhaps we can add a custom Permission class to check against current active SecurityManager/SecurityPolicy if we are allowed to set the config? Altough I've never done this. What do you think? Marc
        Hide
        sean.mullan added a comment -

        This patch contains a potential security hole which can allow untrusted code (ex: an unsigned applet) to replace the xml security configuration which could be part of a trusted installation.

        You can already specify a custom configuration by setting a system property and this is more secure since your code needs to have permission to set that property.

        To the submitter: have you tried specifying your custom config with the
        org.apache.xml.security.resource.config property?

        Show
        sean.mullan added a comment - This patch contains a potential security hole which can allow untrusted code (ex: an unsigned applet) to replace the xml security configuration which could be part of a trusted installation. You can already specify a custom configuration by setting a system property and this is more secure since your code needs to have permission to set that property. To the submitter: have you tried specifying your custom config with the org.apache.xml.security.resource.config property?
        Hide
        Colm O hEigeartaigh added a comment -

        This patch seems fine to me. Sean, can you confirm?

        Colm.

        Show
        Colm O hEigeartaigh added a comment - This patch seems fine to me. Sean, can you confirm? Colm.
        Hide
        Marc Giger added a comment -

        Created an attachment (id=21898)
        allow to pass custom config

        Show
        Marc Giger added a comment - Created an attachment (id=21898) allow to pass custom config

          People

          • Assignee:
            Unassigned
            Reporter:
            Marc Giger
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development