Administrator's Guide

CHAPTER 10

Using Security

This chapter describes ways to provide and restrict access to deployment databases, application servers, and application server clusters. This chapter contains sections on:

Authorization and access control

Access control specifies what operations users are authorized to perform on objects and resources.

Authorization and access control

The application server's authorization and access control settings manage access to:

The server
Deployed applications
Application data

The application server uses security expressions to determine what an identified user is allowed to access.

The application server supports the Java security Access Control List (ACL) API, allowing developers to programmatically control access to data and deployed applications. This Java security works with the security provided by the SMC and the application server's Server Administration API.

For more information about the Server Administration API, see Using the Server Administration API.

You can use the SMC to control access to these resources:

Server directories
J2EE archives deployed to the server
Media objects stored on the server

You specify access by setting the permissions described in Permission types.

Permission types

You use permissions to set up access control on various administration operations and database objects.

Administrative server permissions

The administration resource controls your ability to view and modify administrative settings (and permissions to access settings). Once you have secured the administration resource, unauthorized users will not be able to perform administrative operations.

NOTE: Only members of the Administrators group can access administration settings. To prevent unauthorized users from accessing all administrative information such as who is logged in, session information, permission settings for users and groups, number of connections, and so on, it is important to retain this restriction.

Each of the permission tabs listed in the following table represents an aspect of the administration resource that should remain restricted:

Permission	Description
Read Server Configuration	Limits who can view administration settings and connection parameters.
Modify Server Configuration	Limits who can administer the server or cluster by changing connection parameters such as who is logged in, permission settings for users and groups, number of connections, and so on.
Read Directory Listing	Limits who can browse the server directories. Does not affect whether a user can access an object.
Read Users and Groups	Limits who can see users and groups that have been defined on the server. Users must have this permission in order to set permissions; otherwise, they cannot see the users and groups.
Set Permissions	Limits who can change the permissions that control the administration resource. Anyone with Locksmith privilege will bypass the check for this permission and be able to change the security properties on any object.

Database object permissions

You secure deployment databases by setting permissions on directories and objects (such as J2EE archives). You can restrict access by user or group. Permission settings apply to the directory, all subdirectories (or a specific one), and objects in the directory. Each object or resource within a hierarchy must be secured.

For more information, see Step 10: Secure your deployment databases in the security checklist.

The following permissions apply to objects in a deployment database.

Permission	Description
Read	For an object, limits who can view the object's design information. For a database or directory, limits who can access child objects. To easily prevent users from accessing objects in a database or directory, deny them Read access at the database or directory level. NOTE: Users who need to run an object in a subdirectory must have Read access to all of its parent directories. For more information, see Making secure application objects executable.
Modify	For an object, limits who can change the object. For a database or directory, limits who can add new child objects. To avoid adverse changes to the server, carefully review who has Modify permission to a directory.
Execute (called Default Execute for databases and directories)	Limits who can run application objects (such as J2EE archives) within the selected database or directory. End users typically have Execute permission on objects. Permissions set on an individual application object overrides permissions set on the database or directory.
Set Permissions	Limits who can alter access control information on an object. For example, you may decide that only administrators should be able to change the security properties on an object.

How access works

Different types of server resources have different sets of permissions:

By default, access to server administration operations and database objects is restricted to members of the Administrators group. See Default server and object security.
Most directory levels in the hierarchy allow you to set Read, Write, Execute, and Set Permissions access rights. Each object or resource within a hierarchy can be secured in an identical fashion.
If access rights are defined at the database level, you see all databases but can only expand or open the ones for which you have Read access.
If you have Read access to a particular directory, you can see the named contents of that directory.
Requests for the contents of the named object may be restricted based on permissions set on that object.
You can change security access rights only if you have Set Permissions rights to the deployment database directory or object. You can then use specific access expressions to further limit modifications.
You can secure multiple directories by selecting the Apply To This Directory And All Descendants radio button at the bottom of the permission tabs. You can enable the Require Login For Access check box for selected objects as needed.

For more information, see Making secure application objects executable.

Changing access

You can change object security at the server or cluster level, at the directory level, or at the object level by setting permissions in the SMC.

NOTE: In addition to setting permissions in the SMC, you can also set some types of permissions using SilverCmd SetSecurity, described in the SilverCmd reference chapter of the Facilities Guide.

Procedure To change user access:

Start the SMC.
Select the Security icon from the toolbar.
Select the Permissions panel.

The SMC view changes. All clusters, servers, and databases being administered by the SMC are now expandable, allowing you to list their contents in order to set permissions at the appropriate level:
Select an object or directory and set your permissions as described in Permission types.

Setting permissions on multiple objects You can set permissions on more than one object at a time as long as the objects are in one directory, of the same type, and on the same server: select Shift+Click for contiguous entries or Ctrl+Click for noncontiguous entries and specify the permissions for the selected objects.

Setting the scope of the permissions and whether login is required What radio buttons appear at the bottom of the Permissions panel depend on whether you selected a directory or an object. The following table describes each button option that might appear:

Radio button option	Description	Displays for
Apply to this directory only	Applies permissions only to the selected directory and becomes the default setting for new objects in the directory structure. Does not change permissions for existing objects in the directory.	Directory selections only
Apply to this directory and all descendants	Applies permissions to the selected directory and all existing objects within that directory (including subdirectories) as well as new objects. Overrides any existing settings for existing objects.
Require login for access	Requires the user accessing the object to be authenticated, either by a client certificate or by being logged on. Sets authentication on a per-object basis. You can also require authentication at the server level. See Enabling authentication.	Object selections only

Radio button option

Description

Displays for

Apply to this directory only

Applies permissions only to the selected directory and becomes the default setting for new objects in the directory structure.

Does not change permissions for existing objects in the directory.

Directory selections only

Apply to this directory and all descendants

Applies permissions to the selected directory and all existing objects within that directory (including subdirectories) as well as new objects.

Overrides any existing settings for existing objects.

Require login for access

Requires the user accessing the object to be authenticated, either by a client certificate or by being logged on.

Sets authentication on a per-object basis. You can also require authentication at the server level. See Enabling authentication.

Object selections only

Restricting permissions

Each tab on the form represents a permission type that applies to the selected directory or object. To restrict access, select a tab, deselect Unrestricted, then select either Simple List or Advanced Expression.

CAUTION: If you deselect the Unrestricted check box, be sure to specify either a Simple List or an Advanced Expression; otherwise, no one will have access. This problem will also occur if you clear all previous Simple List entries. If you find yourself in the situation where no one has Read access to the server, you can run SilverMasterInit using the -a command-line option. For more information, see Using the SilverMasterInit program.

Using simple lists

Simple List allows you to specify users and groups that are known to a security provider and have access permission as defined in the provider setup.

Procedure To use simple lists:

Select the Security icon from the toolbar, then select the Permissions panel.
Select the objects or directory you want to set permissions for on the left side of the SMC.
In the Permissions panel, select the tab for the permission type you want to restrict.
To activate the Simple List button, turn off Unrestricted (if selected).
Simple List is the default selection. From the form, select the users and groups to whom you want to grant permission, then click >. To select all users or groups, click >>. Selected users and groups are listed in the list box on the right.

NOTE: A local group that contains a global group (that you defined with the NT User Manager) will appear in the SMC with its individual member names listed (instead of the group name). For more information, see Using NT security.

To remove the permission from a user or group, select the user or group and click <.

To remove all users and groups, select <<.

Using advanced expressions

Use Advanced Expression to build expressions that let you specify access according to specific criteria. To use advanced expressions, select Advanced Expression instead of Simple List (see To use simple lists:). Expressions can include any of the following:

Identity/group membership
Built-in functions, which can perform logical and relational operations

Procedure To use advanced expressions:

Select the objects or directory you want to set permissions for on the left side of the SMC.
In the Permissions panel, select the tab for the permission type you want to restrict.
If selected, turn off Unrestricted; then select Advanced Expression.

The Expression Builder displays selection panes for variables, functions, and operators.

Examples of advanced expressions The following are examples of advanced security expressions:

Use the day() method to disallow access to the object on weekends (the day() function returns a number from 0 to 6, where 0 indicates Sunday, 1 indicates Monday, and so on):
```
  day(now()) >= 1 and day(now())<= 5
```
Similarly, the following expression disallows access to an object except between 9:00 a.m. and 5:00 p.m. Monday through Friday:
```
  (day(now()) >= 1) and
  (day(now()) <= 5) and
  (hour(now()) >= 9) and
  (hour(now()) <= 17)
```

UUID support

The Expression Builder supports Universally Unique Identifiers (UUIDs) for security expressions. These provide a more secure system than simple integer IDs. UUIDs are used by default in simple security expressions and are available in advanced expressions.

You can enter UUID expressions directly in the Expression Builder, or choose them from the ID section in the Expression Builder's Functions panel:

Function	Description
userID()	Finds the UUID of the user currently logged on.
userID('name')	Finds the UUID of a specific user. To create a qualified name, start with the security realm (SSSW, NT, LDAP, or NIS+), add security authority (such as the NT domain name or LDAP/NIS+ server name), then add the user name. Separate each component with two backslashes (\\). (You need to escape backslashes in user names by doubling the backslashes to four.) By default, if both the realm and authority are missing, a Silver Security user is assumed. By default, if the realm is missing, an NT user is assumed, with the first component assumed to be the NT domain. For example: userID('bobh') refers to the Silver Security user bobh (user defined in Silver Security) userID('DEVA\\JWilkins') refers to the NT user JWilkins, who is in the NT domain DEVA
groupID('name')	Finds the UUID of a specific group. Group names, like user names, consist of a qualified name. For example: groupID('Administrators') refers to the Silver Security Administrators group groupID('DEVA\\Accounting') refers to the NT Accounting group in the DEVA domain
UUID('uuidString')	Finds the UUID corresponding to the string representation of a UUID. This form is used when a group ID or user ID cannot be resolved. The application server translates names into corresponding UUIDs before storing them in the AgAccessRights system table. Similarly, when the client views the expression, the internal form is translated back into human-readable names. If an internal UUID cannot be translated (for example, if it has been deleted), UUID() is used.

Examples The following are examples of security expressions using UUID:

This example restricts access to the Silver Security users administrator and bobh:
```
  userID() in (userID('administrator'),userID('bobh'))
```
This example restricts access to the Silver Security user bobh and the NT user JWilkins, who is in the NT domain DEVA:
```
  userID() in (userID('bobh'),userID('DEVA\\JWilkins'))
```
This example restricts access to the Silver Security user administrator and any user in the Silver Security Developers group:
```
  userID() in (userID('administrator')) or userID() userin (groupID('Developers'))
```
This example restricts access to the Silver Security user administrator and any user in the NT Accounting group, which is in the DEVA domain:
```
  userID() in (userID('administrator')) or userID() userin (groupID('DEVA\\Accounting'))
```

Making secure application objects executable

When you are securing deployment databases, you also need to make sure users can run deployed applications such as EARs, WARs, and EJB JARs.

J2EE archives are deployed to the Deployed Objects directory of the deployment database, so the deployer needs Write permissions to that directory.
To allow users to run the deployed archives, you usually assign them unrestricted Execute permission at the directory level (including all descendants).

Procedure To make secure database objects executable:

Log in to the SMC as an Administrator or a user with Locksmith privilege.
Select the Security icon from the toolbar.
Select Permissions.
Select the server and database you want to change.
Set the initial group permissions as follows:
1. Assign Read and Modify permissions to developers and administrators.
2. Assign Set Permissions access to administrators.
3. Assign unrestricted Execute permission to end users.
IMPORTANT: Select the Apply to this directory and all descendants check box on all of the preceding tabs.
Click Update.
Select Deployed Objects.
Select the Unrestricted check box on the Read permission tab—but do not click Apply to this directory and all descendants.
Click Update to save these settings.
Apply the same Read permission settings (as in Step 8) to all major directories of your application that you want users to access. While these settings give users access at the parent directory level, they also let you restrict individual objects within those directories.
Review individual objects to determine if the Require login for access option should be enabled.

Default server and object security

If you choose the installation default, the application server initializes the SilverMaster database. When access to SilverMaster is restricted, all users (except those in the Administrators group) are unable to access administration operations, add databases, and browse directory listings. If your application server is running in a restricted production environment, all users will be required to authenticate themselves when accessing the server.

If you did not choose the Restrict Access to the Novell exteNd Application Server installation option, your server resources are not locked down. Installing the application server with unrestricted access means that unauthorized users can perform administrative operations and browse directory listings until you lock down access by setting permissions.

For more information See Ways to lock down a server for other ways to lock down the server.

Default object security

Object security defaults are as follows:

Users have runtime Read and Execute access to all objects (except administration objects.)
If you define a particular access at the directory level, it becomes the default access for any new objects created within that directory. A directory is a container for objects of one type (like Deployed Objects). When you have selected the Permissions panel in the SMC, you can expand directories to see their contents (assuming you have Read permission on that directory). Any new object takes on the access security of the immediate parent object.

Default group permissions

During installation, SilverMasterInit creates two predefined groups (Administrators and Developers) and sets permissions for both groups. The server requires all users to log in. By default, access to server administration operations is restricted to members of the Silver Security Administrators group for a locked-down server. Access to administration resources (such as who can use the SMC, view session and statistical information, or add and remove users and groups) is only granted to members of this group.

You typically separate who is allowed to read an object from who is allowed to write it. You may also want to define a separate group (such as end users) with Execute permission.

For more information about predefined Silver Security groups, see About Silver Security users and groups.

NOTE: By default, users will have Read access to the top level of the SilverMaster database and directories that will enable them to log in and access any existing deployment databases.

For more information, see Making secure application objects executable.

Locking down servers, clusters, and applications

At some point in the development and deployment process, you will want to lock down a deployment database, a server, and/or an entire cluster. Locking down these items helps secure your production and deployment environments by making sure the appropriate access permissions are set.

For example, when deploying an application, you might want to lock down the deployment database so no one can access it except you, then progressively unlock it as appropriate in the production environment.

CAUTION: If you did not choose the Restrict Access to the Novell exteNd Application Server installation option, your server resources are not locked down. Even if you aren't ready to lock down and deploy your applications, you should nevertheless lock down your server.

Ways to lock down a server

The following sections describe different ways you can restrict server access:

Section	Contents
Default server and object security	Describes default application server installation settings
Using the SMC to lock down the server or an application	Describes how to use the SMC to lock down the server or an application
Using SilverCmd to lock down the server, an application, or a cluster	Describes how to use SilverCmd to lock down the server, an application, or a cluster
Security checklist	Provides a list of steps for ensuring that your server is secure
Excluding robots	Describes additional considerations when configuring an application development environment

Using the SMC to lock down the server or an application

Procedure To lock down the specified server:

Restrict the Read Server Configuration, Modify Server Configuration, Read Directory Listing, Read User & Groups, and Set Permissions permissions at the server or cluster level to members of the Administrators group.
Select the SilverMaster database and restrict Read, Modify, and Set Permissions permissions to members of the Administrators group and apply that restriction to all descendants.
Set unrestricted Read access to the SilverMaster database to allow users (with appropriate permissions) to access other databases and log in to the server.

For more detailed instructions, see Step 9: Secure the SilverMaster database in the security checklist.

Procedure To lock down the selected application:

Restrict the Read, Modify, Default Execute, and Set Permissions permissions at the database level to members of the Administrators group and apply the restriction to all descendants.

Using SilverCmd to lock down the server, an application, or a cluster

Included with the application server (in the server's \Samples\SilverCmd directory) are three sample XML files that are input files for the SilverCmd SetSecurity command. These files show how you can lock down an application, a server, or a cluster using SilverCmd. All three files are well commented with usage notes.

This secure file	Shows you how to lock down	You might want to apply this file
secure_server_sample.xml input file	An entire server	To a server when putting it into production
secure_application_sample.xml input file	An application	To an database just before deploying it in order to secure it properly
secure_cluster_sample.xml input file	A cluster	After you have secured each server in a production cluster using secure_server_sample.xml

For more information For information on using SilverCmd, see the SilverCmd Reference chapter of the Facilities Guide.

Securing the production server

The levels and types of security you implement depend on the scale and demands of your particular enterprise. Once your application is ready to deploy (or even if it is already deployed), you should go through each step in the following security checklist to secure your production environment.

If you chose the installation default, the application server restricts access to the SilverMaster database. When access to SilverMaster is restricted, unauthorized users will not be able to access administration operations and browse directory listings.

During application development, you may have opened up access to specific applications and directories. Once your applications are built, it is up to you to make sure that all resources are protected from unauthorized access.

Security checklist

TIP: To test your site's security, run any accompanying tests for each step.

Step 1: Design firewalls

Make sure the application server is installed behind any firewalls your company uses.

For more information, see Server configurations.

Step 2: Set up a unique database account

Set up a unique database account for the application server to use to connect to each deployment database.

For more information, see Data Source Configuration.

Step 3: (Optional) Set up SSL

If you intend to use SSL communications, obtain a server certificate and install it on the server. You also need to enable the RSA and/or DSA ports and disable HTTP if you want to require only SSL.

For more information, see Using certificates.

Step 4: (Optional) Set up unique ports

For added security, configure separate runtime and administration ports. The server supports ports for the HTTP, HTTPS-RSA, and HTTPS-DSA security protocols. Each unique port you configure excludes URLs and operations that are not associated with it. The separate ports are designed to work in conjunction with your server permission settings.

For more information, see Setting up separate ports.

Step 5: Set up users, groups, and security providers

User and group information can be defined using Silver Security or obtained from an external security system. For Silver Security, all information is stored in the SilverMaster database. For external security, all information is obtained from the external system. In either case, define access to directories and objects.

For more information, see Managing Silver Security users and groups.

Step 6: Require authentication at the server

If you restrict the Execute access to all resources in your SilverMaster database, you must enable Require user authentication at the server level. Otherwise, requiring user authentication is optional.

When a user can access the server without logging in or sending in a certificate, the user is considered Anonymous. It is often a good idea to prohibit Anonymous user access by forcing users to authenticate themselves when they first access the server, through either a certificate or a user ID/password pair. You can also require login on a per-object basis.

Procedure To test for unauthorized user access:

To assess the Anonymous user's ability to access your site, enter an URL to your application into a browser such as:
```
  http://localhost/
```
If the browser displays a login dialog, your site is requiring anonymous users to authenticate themselves.

If the default page or a listing of your site's directory contents (or a Read Access Denied message) displays, your site is allowing anonymous access and you may want to complete the following procedure to require user authentication.

Procedure To require user authentication:

Start the SMC and select a server from the left pane.
Select the Security icon from the toolbar.
Select General.
Check the Require user authentication check box.
Click Update to save the settings.

For more information, see Enabling authentication.

Step 7: Restrict the directory listing on the server

The application server displays a directory listing when users request certain URLs from a browser. Although a listing of directory entries may not seem critical to your site's security, you might want to prevent these lists from appearing.

To see whether unauthorized users can access the HTML and non-HTML directory listings, run the following two procedures.

Procedure To check whether the HTML directory listing is enabled (and optionally disable it):

From your browser, enter the URL of a directory on your server such as:
```
  http://localhost/SilverStream/Meta/
```
If your HTML directory listing is protected, the following error message displays:
```
  You are not allowed to read the specified resource.
  Additional technical details about this error are available.
```
If an HTML directory list displays, you can disable the directory listing access described in the following steps.
Open the SMC and select the Security icon from the toolbar.
Check the Disable HTML directory listing check box.
Click Update to save the settings.

Procedure To check whether the non-HTML directory listing is enabled (and optionally disable it):

From your browser, enter an URL from a browser such as:
```
  http://localhost/SilverStream/Meta/?access-mode=text
```
If your non-HTML directory listing is protected, the following error message displays:
```
  You are not allowed to read the specified resource.
  Additional technical details about this error are available.
```
If you see the directory contents listed in plain text, you can disable directory listing access as described in the following steps.
Open the SMC and select the Security icon from the toolbar, then select Permissions.
Set the Read Directory Listing permission to limit access as described in To check the Read Server Configuration setting of your administration resource:.
Click Update to save the settings.

For more information, see Enabling authentication.

Step 8: Secure the administration resource

The administration resource controls your ability to view, modify, and change administrative settings (and permissions to access settings). You secure server objects by restricting permissions on the administration resource. Once you have secured the administration resource, unauthorized users will not be able to perform administrative operations.

Run the following two tests to check access to your server. But even if the test URL does not access protected server information, you should use the SMC to verify that your administration resource security settings properly restrict access to the appropriate users.

Procedure To check the general accessibility of your administration resource:

Open the SMC.
As an anonymous user, try to view and change application objects.

On a secure server you see:
```
  Read Access Denied. 
  Additional technical details about this error are available.
```
If you are able to view or change application objects, you should promptly run the procedure To protect administration access:.

Procedure To check the Read Server Configuration setting of your administration resource:

Enter the following URL for your Web site:

  http://localhost/SilverStream/Administration/

On a secure server you see:

  Read Access Denied. 
  Additional technical details about this error are available.

If you see a listing of site-specific server properties (similar to the following text sample) listed in plain text, your site is not protected.

  com.sssw.loadbalancer.connect.tryInterval=30
  com.sssw.srv.server=exteNd ApplicationServer/n.n
  com.sssw.srv.http.ClientPool.minIdle=0
  com.sssw.loadbalancer.connect.sleepCount=10
  com.sssw.srv.http.ClientPool.minFree=10

If the administration resource at your site is not protected, you should promptly run the procedure To protect administration access:.

CAUTION: If you discover that your administration resource was left unrestricted, you should immediately change the user name and password for each database. These steps will help ensure that anyone who may have accessed this information while the resource was unrestricted can no longer use it.

Procedure To protect administration access:

Start the SMC and select a server from the left pane.
Select the Security icon from the toolbar.
Select Permissions.
On each permission tab, deselect the Unrestricted check box to restrict access.

It is especially important that you restrict the Read Server Configuration permission by deselecting the Unrestricted check box.
Select either Simple List or Advanced Expression.
Select the users and groups or define an expression that specifies who will be assigned the permission on the selected tab. You should limit access on all five tabs (listed in the table in Administrative server permissions) to members of the Administrator group (it is given to both Developers and Administrators by default).

For more information, see Permission types.

Step 9: Secure the SilverMaster database

Special care should be taken when securing the SilverMaster database. In addition to storing resources such as user and group information, SilverMaster stores the login resource and references to all other deployment databases available to the server.

Unless your applications are tightly controlled, you don't typically apply Read restrictions to the SilverMaster database. You must allow Read access to the top level of the SilverMaster database in order for users to be able to access anything on the server. You may want to lock down all resources below the main directory level.

If you accidentally restrict Read access to your SilverMaster database, enable Require user authentication on the Server Security panel. If you forget to require authentication, run SilverMasterInit with the -a option to enable user authentication from the command line. You will need to restart the server for the authentication change to take effect.

Procedure To test access to your SilverMaster database:

To see whether your SilverMaster database can be accessed by unauthorized users, follow Step 10: Secure your deployment databases.

In Step 4 of that procedure, select the SilverMaster database you think you've restricted. Select an object stored below the SilverMaster parent level to test access.

Procedure To lock SilverMaster resources below the main directory level:

Open the SMC as an administrator and select the Security icon from the toolbar.
Select Permissions.
In the left panel, select the SilverMaster database below the desired server.
Restrict Read, Modify, and Set Permissions to members of the Administrators group and then click the Apply to this directory and all descendants radio button. For more information about permission settings, see the table in Administrative server permissions.
Click Update to save the settings.
Reselect the SilverMaster database and set unrestricted Read access (make sure the Apply to this directory only is selected).
Click Update to save the settings.
Repeat Step 6 and Step 7 for each of the directories and subdirectories expanded below SilverMaster (such as Deployed Objects).
Click Update to save the settings.

For more information, see Configuring deployment databases.

Step 10: Secure your deployment databases

You should restrict user access to deployment databases by setting permissions on directories and objects.

Understanding permission settings Permission settings apply to the directory, all subdirectories, and any objects in the directory or any subdirectory. For each application, review every object and specify who is allowed Read, Write, Default Execute, and Set Permission access on each directory level in the hierarchy. Each object or resource within a hierarchy must be secured.

Unless you set restrictions, all users have full access permissions on objects. If you define a particular access on a directory, it becomes the default access for any new objects created within that directory. When you have selected the Permissions panel in the SMC, you can expand directories to see their contents (assuming you have Read permission on that directory). You can secure multiple directories by selecting the Apply to this directory and all descendants radio button at the bottom of the permission tabs. You can enable the Require login for access check box for selected objects as needed.

NOTE: If your application objects contain EJBs, you must unrestrict Read access to the parent directory of the objects directory (and to all descendants), since the object directory contains classes that need to be read by the application.

Procedure To test access to database objects (and optionally secure them):

Log in to the SMC as an Administrator or user with Locksmith privilege.
Select the Security icon from the toolbar.
Select Permissions.
In the left panel, select an object that you think should be restricted that is stored below the parent level of the directory structure.
Click each tab and see who has access to this object. Complete the following steps if the permission restrictions are not set correctly.
Click each tab and select either Simple List or Advanced Expression.
Select the users and groups or define an expression that specifies who will be assigned the permission on the selected tab.
Make sure that someone in the Administrator group has Set Permission access to this object.
Click Update to save the settings.

For more information, see Database object permissions and Making secure application objects executable.

Step 11: Map J2EE security roles

When deploying J2EE archives, map the security roles specified in the deployment descriptor to security principals in the production environment. For example, if the bean developer has defined three security roles, these same roles must be mapped to security groups or individual users on the target server. If you decide to map roles to groups (for ease of maintenance), be sure to verify group membership.

Excluding robots

Robots are programs, such as search engines and Web crawlers, that can traverse many pages on a Web site by recursively retrieving linked pages. The application server supports the commonly used robot exclusion protocol that allows you to specify exactly what files and directories robots that conform to the exclusion protocol can access on your Web site.

NOTE: The robot exclusion protocol is purely voluntary. There is no guarantee that a robot conforms to the protocol—but most do.

In this exclusion protocol, the access policy for robots is specified in a file called robots.txt. The robots.txt file shipped with the application server tells robots not to proceed below the root of the server (in other words, it disallows all access to all robots that conform to the exclusion protocol). So by default, conforming robots are disallowed all access to your Web site.

You can modify robots.txt to specify the kind of access you want to provide to robots. For example, you might want to allow search-engine access to some directories but not to others.

Procedure To modify robot access:

Edit robots.txt in the server's \Resources directory.

For information about the protocol's format and semantics (including examples), see http://www.robotstxt.org/wc/robots.html.

The next time a conforming robot requests the access policy from the server, the updated robots.txt file will be read and the information sent back to the robot.