Secured application does not prompt user to log in
 Technote (FAQ)
 
Problem
A secured application does not prompt for login. Users are able to access the application in a web browser without supplying a username and password.
 
Cause
Failure to regenerate the web server plugin or missing a step during security configuration
 
Solution
1. Often the problem can be resolved by regenerating the web server plugin from the admin console or by running <install_root>/bin/GenPluginCfg.sh

2. If regenerating the plugin doesn't work, review the application security tutorial under "Related Information' at the end of this page for a step by step guide on configuring application security.

You can also use the XML export of the administrative console to determine which security configuration step(s) were missed.

To export the administrative console, start the administrative console and click on Console > Export. Provide a filename and location and hit "Apply". Alternatively, you can run /<Install_Root>/bin/xmlconfig.sh from the command line.

With WebSphere Application Server 3.5 and 4.0 security configuration information is displayed in the export of the administrative console (xmlconfig). This makes desk-checking the xmlconfig file a good tool to verify security configuration.

Assuming that the 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 a configuration task was missed or skipped.

 
Related information
Application Security Tutorial
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Security
Operating system(s): HP-UX
Software version: 4.0.7
Software edition:
Reference #: 1006937
IBM Group: Software Group
Modified date: Aug 14, 2005