3

I have a docker image of a websphere liberty based application. By default, this image uses Basic Authentication with a basicRegistry that has a couple sample users. The basicRegistry group is then bound to a security-role as follows (and this security role is referenced from the application's web.xml):

<webApplication id="myWebapp" ...>
    <application-bnd>
        <security-role name="Users">
            <group name="Users"/>
        </security-role>
    </application-bnd>
</webApplication>

Now, in my environment, authentication will be handled outside of this container, and so I want to disable the basic auth check and make this open to everyone that can get to it. Rather than repackaging the whole server.xml, I was hoping to just add some configuration to configDropins/override in order to disable authentication for the webapp.

After trying it, I'm rather confused about whether/how this is supposed to work... Here is the observated behavior:

If I first start the server, then add a config snippet to configDropins/override such as the following:

<webApplication id="myWebapp">
    <application-bnd>
        <security-role name="Users">
            <special-subject type="EVERYONE"/>
        </security-role>
    </application-bnd>
</webApplication>

Then the webapp will reload and basic auth is turned off (good).

However, when I package this same config snippet in configDropins/override and then start the server, the webapp starts up with basic auth enabled and all requests fail with an HTTP 401 status.

Can anyone help me understand this behavior and/or offer an alternative approach?

lmsurprenant
  • 1,723
  • 2
  • 14
  • 28

1 Answers1

0

Adding an "id" attribute to the security-role element should resolve this. In your example, there are essentially two security-role elements after configuration processing. The security runtime will merge them together based on the name, but the behavior will vary based on the order in which the two security-role elements are received.

Brent Daniel
  • 355
  • 1
  • 4
  • Thank you for this answer. Unfortunately, even after adding an `id` attribute to the security-role element on both the server.xml and the override.xml, I'm seeing a 401 error with an error response like: ```[ERROR ] CWIML4537E: The login operation could not be completed. The specified principal name **** is not found in the back-end repository. ...``` – lmsurprenant Jan 03 '19 at 18:18
  • Is there a description of the algorithm used for the override somewhere? Do I need to wrap the security-role element in the override.xml in a webApplication like in my example? In my server.xml I include other attributes and elements for this webApplication, but my assumption was that these would somehow get merged into a single webApplication definition since they have the same id. – lmsurprenant Jan 03 '19 at 18:23
  • Hmmm, maybe it *is* working after adding the id attribute as described. I thought I was still seeing the error, but after some more config tweaking, this seems to be working now. Maybe I didn't give it a clean start after trying it the first time?! Anyway, will accept this as the answer unless this error comes back. Thanks again! – lmsurprenant Jan 03 '19 at 18:45
  • 1
    The rules can be found at https://www.ibm.com/support/knowledgecenter/en/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/cwlp_confg_element_merging_rule.html In your case, the two web application elements do merge together because they have the same ID. The application-bnd elements merge together because there can only be one. The security-role elements do not merge together (as far as the configuration runtime is concerned) because there can be multiple elements and they don't have ID values. This case is weird bc the security runtime does merge them by name. – Brent Daniel Jan 03 '19 at 19:21
  • I got the 401 again :-( Is it possible this is still not determinant? Possibly the `` isn't getting merged? I added an `id` attribute to this `` element and its working again. Will report back if I see the 401 again. – lmsurprenant Jan 04 '19 at 19:11