Administrator's Guide
CHAPTER 10
This chapter describes ways to provide and restrict access to deployment databases, application servers, and application server clusters. This chapter contains sections on:
Access control specifies what operations users are authorized to perform on objects and resources.
The application server's authorization and access control settings manage access to:
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:
You specify access by setting the permissions described in Permission types.
You use permissions to set up access control on various administration operations and database objects.
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:
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. |
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.
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.
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 |
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.
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.
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 <.
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:
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)
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:
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'))
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).
To make secure database objects executable:
Log in to the SMC as an Administrator or a user with Locksmith privilege.
Set the initial group permissions as follows:
IMPORTANT: Select the Apply to this directory and all descendants check box on all of the preceding tabs.
Select the Unrestricted check box on the Read permission tabbut do not click Apply to this directory and all descendants.
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.
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.
See Ways to lock down a server for other ways to lock down the server.
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.
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.
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.
The following sections describe different ways you can restrict server access:
Section |
Contents |
---|---|
Describes default application server installation settings |
|
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 |
Provides a list of steps for ensuring that your server is secure |
|
Describes additional considerations when configuring an application development environment |
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.
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.
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.
For information on using SilverCmd, see the SilverCmd Reference chapter of the Facilities Guide.
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.
TIP: To test your site's security, run any accompanying tests for each step.
Make sure the application server is installed behind any firewalls your company uses.
For more information, see Server configurations.
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.
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.
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.
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.
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.
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.
To require user authentication:
For more information, see Enabling authentication.
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.
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.
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:.
For more information, see Enabling authentication.
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.
To check the general accessibility of your administration resource:
As an anonymous user, try to view and change application objects.
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:.
To check the Read Server Configuration setting of your administration resource:
Enter the following URL for your Web site:
http://localhost/SilverStream/Administration/
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.
To protect administration access:
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 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.
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.
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.
To lock SilverMaster resources below the main directory level:
Open the SMC as an administrator and select the Security icon from the toolbar.
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.
Reselect the SilverMaster database and set unrestricted Read access (make sure the Apply to this directory only is selected).
Repeat Step 6 and Step 7 for each of the directories and subdirectories expanded below SilverMaster (such as Deployed Objects).
For more information, see Configuring 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.
To test access to database objects (and optionally secure them):
Log in to the SMC as an Administrator or user with Locksmith privilege.
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.
For more information, see Database object permissions and Making secure application objects executable.
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.
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 protocolbut 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.
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.
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...