Using XML export to verify that resource is secured

Technote (FAQ)
Problem
Using XML export to verify that resource is secured
Solution
I have a customer who states that they have gone through the steps for securing a servlet, but when they access the servlet through a browser, they don't get challenged. How can I tell whether they've done everything they need to?

With WebSphere Application Server 3.022 and later, security configuration information is displayed in xmlconfig output. This makes desk-checking the xml config file a good way to verify security configuration, and answer both of these questions.

Assuming that a customer's global security settings are correct, the following tasks need to happen for a resource such as a servlet to be secured (these are tasks in the admin console):

  1. An Enterprise Application needs to be created, and the EJBs, web applications and/or URIs to be secured are added to the Enterprise Application
  2. The Enterprise Application should be configured
  3. The EJBs, web app which contains the resource and/or the URIs need to be secured. This is where method groups are assigned to methods of the resource
    1. Custom method groups may created and assigned instead of the default method groups
  4. Permissions are assigned to the method groups
  5. WebSphere Application Server security is enabled

Here's how to analyze an xml export of a WebSphere configuration to verify that the above tasks have been completed:

For (1), there should be a block beginning like the following containing references to any EJBs to be secured, web apps containing servlets to be secured, as well as (in the case of html files not served by WebSphere but which are secured) individual URIs:

<enterprise-application name="MyEntApp" action="create">
<ejb name="MyEJB"/>
<web-application name="myWebApp"/>
<uri name="/MyStupidFile.html"/>
</enterprise-application>

For (2), there should be a enterprise-application-security block with the following properties within:

<enterprise-application-security action="update">
<enterprise-application>
<realm-name>
<challenge-type>
<app-auth-data>
</enterprise-application-security>

For (3), each ejb or uri of a resource to be secured should have a block such as the following:

<ejb-security>
<ejb name="MyEJB"/>
<method-group-mapping method="afterConnect" method-group="ExecuteMethods"/>
<method-group-mapping method="connect" method-group="ExecuteMethods"/>
<method-group-mapping method="ejbGetEJBMetaData" method-group="ExecuteMethods"/>
<method-group-mapping method="ejbRemove" method-group="RemoveMethods"/>
<method-group-mapping method="ejbCreate" method-group="CreateMethods"/>
<run-as-mode-mapping method="*" run-as-mode="system"/>
</ejb-security>

<uri-security>
<uri name="/webapp/myWebApp"/>
<method-group-mapping method="HTTP_GET" method-group="ReadMethods"/>
<method-group-mapping method="HTTP_POST" method-group="ReadMethods"/>
<method-group-mapping method="HTTP_PUT" method-group="WriteMethods"/>
<method-group-mapping method="HTTP_DELETE" method-group="RemoveMethods"/>
</uri-security>

For (3a), there should be blocks similar to the following default method group blocks:

<method-group>ReadMethods</method-group> <method-group>WriteMethods</method-group> <method-group>RemoveMethods</method-group> <method-group>CreateMethods</method-group> <method-group>ExecuteMethods</method-group> <method-group>FinderMethods</method-group>

For (4), there should be a block as follows:

<permission app-name="MyEntApp" method-group="ExecuteMethods">
<access-id>*AllUsers</access-id>
</permission>
<permission app-name="MyEntApp" method-group="CreateMethods">
<access-id>*AllUsers</access-id>
</permission>
<permission app-name="MyEntApp" method-group="ReadMethods">
<access-id>*AllUsers</access-id>
</permission>
<permission app-name="MyEntApp" method-group="WriteMethods">
<access-id>*AllUsers</access-id>
</permission>
<permission app-name="MyEntApp" method-group="RemoveMethods">
<access-id>*AllUsers</access-id>
</permission>
<permission app-name="MyEntApp" method-group="FinderMethods">
<access-id>*AllUsers</access-id>
</permission>

For (5), there should be a block that starts with:

<security-config security-enabled="true" security-cache-timeout="600">

If any of these are missing, it is likely that the user has missed or skipped a security configuration task.












    Document Information

    Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, Security
    Operating system(s): Multi-Platform
    Software version: 3.0.2.x, 3.5
    Software edition: Standard, Advanced
    Reference #: 1006937
    IBM Group: Software Group
    Modified date: 2002-02-05