Administrator's Guide
|
|
Administrator's Guide |
SilverStream authorization and access control security settings work together to let you manage access to the server and application data. Authorization uses security expressions to determine what an identified user is allowed to access.
This chapter describes ways to provide and restrict access to application databases, a server, and/or an entire cluster. This chapter contains sections on:
Access control specifies what operations users are authorized to perform on different types of application objects and resources. Authorization occurs after users authenticate themselves while using the application. You can modify access settings while the application is running by selecting individual resources on the server (tables, forms, views, and so on) and specifying who is allowed to access them.
SilverStream supports the Java security Access Control List (ACL) API, allowing developers to programmatically control access to any SilverStream object, including data and application objects. This Java security works with the security provided by the SMC and the SilverStream Server Administration API.
For more information about the SilverStream API, see
Using the Server Administration API.
You can use the SMC to control SilverStream server administration at the server or cluster level and to control access to the following:
You specify access by setting the following permissions.
SilverStream allows you to set up access control on various administration operations and database objects through permissions.
The administration resource controls your ability to view, modify, and change 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 groups 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.
Secure your application databases by setting permissions on directories and objects such as pages, views, and business objects. Decide whether to restrict access by user or group, using simple lists or advanced expressions. Permission settings apply to the directory, all subdirectories, and objects in the directory or any subdirectory. Each object or resource within a hierarchy must be secured.
For more information, see
Step 10: Secure your application databases in the Security checklist.
The following permissions apply to database objects (such as tables, forms, views, and so on). The permission names on the tabs vary slightly depending on which object is selected.
|
Permission |
Description |
|---|---|
For an object, limits who can view an 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. | |
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 your server, carefully review who has Modify permission to a directory. For example, a user with Modify access to the Pages directory is able to create new page objects. Write access to directories should only be assigned to developers and/or administrators. | |
Limits who can run application objects (such as pages, forms, views, and so on) within the selected database or directory. End users typically have Execute permission on objects. | |
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 this object. | |
Lets the user set up row-level retrieval access on individual tables by creating selection criteria through the Expression Builder. This is useful if you want to set up row-level security in a table. To restrict Write access to the table's data, you need to write a business object. For more information, see the chapter on table-modified business objects in the Programmer's Guide of the server's Classic Development Help. |
Different types of resources (servers, table, objects, images, and so on) have different sets of permission that correspond to their functions.
For more information, see
Making secure application objects executable.
By default, access to server administration operations and database objects is restricted to members of the SilverStream 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 expressions set on that object.
You can change security access rights only if you have Set Permissions rights to the SilverStream 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.
If your application objects contain EJBs, you must make sure that Read access to the parent directory of the objects directory (and to all descendants) is unrestricted, since the object directory contains classes that need to be read by the application.
For more information, see Step 11 in the
Security checklist.
To restrict Write access to rows on INSERT, UPDATE, or DELETE, you can create business objects that enforce access restrictions.
For more information, see the chapter on table-modified business objects in the Programmer's Guide of the server's Classic Development Help.
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 permissions at the command line using a SilverCmd utility. For more information, see SetSecurity in the SilverCmd Reference in the Facilities Guide of the server's Core Help.
The SMC view changes: all the clusters, servers, and databases being administered by the SMC are now expandable, allowing you to list their contents in order to set permissions at any level you want.
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 all the objects are in one directory (that is, the objects are all the same type, such as forms or pages, and on the same server): select Shift+Click for contiguous entries or Ctrl+Click for noncontiguous entries and specify the permissions for all the selected objects.
Setting the scope of the permissions and whether login is required The radio buttons that appear at the bottom of the Permissions panel depend on whether you selected a directory or an object. The following is a description of each button option that might appear.
|
Radio button option |
Description |
|---|---|
Appears for directory selections 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. | |
Appears for directory selections only. Applies permissions to the selected directory and all existing objects within that directory (including subdirectories) as well as new objects. | |
Appears for object selections only. 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. |
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 modify the Simple List or 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.
This option allows you to specify users and groups that are known to a security provider and have access permission as defined in the provider setup.
In the SMC, select Security options, 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 users or groups, select the user or group and click <. To remove all users and groups, select <<.
Use this option to build expressions that let you specify access according to particular criteria. To use advanced expressions, select Advanced Expression instead of Simple List (see the previous procedure). 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 and select Advanced Expression.
The SilverStream 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 and 5:00, Monday through Friday:
(day(now()) >= 1) and (day(now()) <= 5) and (hour(now()) >= 9) and (hour(now()) <= 17)
For more information about specifying expressions, see the chapter on expressions in the Programmer's Guide of the server's Classic Development Help.
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 access them from the ID section in the 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 SilverStream user administrator and any user in the SilverStream Developers group:
userID() in (userID('administrator')) or userID() userin (groupID('Developers'))
This example restricts access to the SilverStream 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'))
For more information about specifying expressions, see the chapter on expressions in the Programmer's Guide of the server's Classic Development Help.
You can perform database table and row-based access control through the SELECT expression on a table. Row-level expressions work as follows:
If selected, turn off Unrestricted and select Advanced Expression.
Select the column in the left panel and write an expression.
Examples of SELECT expressions The following are examples of row-level SELECT expressions.
This example uses a group and a table column called SalesCode. The SELECT expression will show orders whose sales codes are between 100 and 200 only to users who are in the Northeast sales group.
userID() userin (groupID('NorthEast-Sales')) AND orders.SalesCode BETWEEN 100 AND 200
This example uses an if...then statement to use a conditional expression. The following SELECT expression will show employees whose status is 3 only to managers.
if (userID() userin(groupID('Managers')))
then (employees.status>0)
else (employees.status<>3)
endif
For more information about specifying expressions, see the chapter on expressions in the Programmer's Guide of the server's Classic Development Help.
The INLIST operator is a SilverStream construct that can be used in an advanced SELECT security expression. For example, you may have special columns in your tables that contain information about who can view them. The rows are retrieved and then filtered through this expression using the column's values.
The Project table has a column called Allowed_Groups, which has a type varchar(100).
The first row has the following value for Allowed_Groups: "Administrators Developers Designers".
The second row has the following value for Allowed_Groups: "Administrators"
The third row has the following value for Allowed_Groups: "Administrators Developers".
Suppose a user named Dev1 belonging to the Developers group logs in to the server. The following shows the SELECT security expression on table Project:
user() userin (inlist(PROJECT.ALLOWED_GROUPS))
Next, Dev1 creates a form against Project table and runs it. The server retrieves three rows and applies the SELECT expression to every row before giving the form back to the client. Because Dev1 belongs to the Developers group, the server shows only the first and third rows, but not the second row, which is restricted to the Administrators group.
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 SilverStream 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 SilverStream tells robots not to proceed below the root of the server (that is, it disallows all access to all robots that conform to the exclusion protocol). So by default, conforming robots are disallowed all access to the Web site you have developed with SilverStream.
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 SilverStream\resources directory.
For information about the protocol's format and semantics, including examples, see http://info.webcrawler.com/mak/projects/robots/norobots.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.
When you are securing application databases, you also need to make sure that users can run necessary database objects such as forms and pages.
Typically, administrators and developers have Read and Write permissions at the database and parent directory level, along with Read, Write, and Execute permissions on database objects. Because Read and Write permission allows users to be able to see and (respectively) change the source code, you would typically assign these permissions only to developers and/or administrators. The Set Permissions access is usually limited to server administrators.
To allow users to run forms, pages, objects, and so on, you usually assign them unrestricted Execute permission at the directory level (including all descendants) and on all objects they need to run. Because users who need to run an object in a subdirectory need Read access to all of its parent directories, you must take special care when setting access to objects in a database or directory. For example, if a subdirectory contains a form or page that users need to run, you must grant them unrestricted Read access to both the database and the parent directory. This situation is typically the only time you assign users unrestricted Read access. You may also want to publish to your production server without source to prevent users from viewing source code and design information.
As shown in the following figure, anyone can run Form A, but only members of the Users and Developers groups can run Form B. Because Form A has unrestricted Execute access, Read access must also be set to unrestricted on the Forms directory. If Read access on the Forms directory were limited to Developers and Users, only those users would be able to run Form A.
Servlet URLs With servlets and pages, you can create your own directory hierarchies for their URLs. Because the SMC cannot show their directory hierarchies, you cannot use the SMC to set permissions on these types of objects. You can set these permissions in either of the following two ways:
By using the permission settings inherited from the parent database. If you correctly set permissions on the database before you save the servlet or page and create the URL hierarchy of the servlet or page, the correct permission settings will be inherited.
By using SilverCmd. Once the servlet or page is created, use SilverCmd to specify the URL path hierarchy in the XML command file.
When setting permissions, you typically start at the top of the directory structure and set broad restrictions that you then refine. You then work your way down through the directory structure and open up object Read access to appropriate users and groups as needed. Enable the Require login for access check box for selected objects as needed.
To make secure database objects executable:
Log in to the SMC as an Administrator or user with Locksmith privilege.
Select the server and application database you want to change.
Set the initial group permissions as follows and then click Update:
NOTE Select the Apply to this directory and all descendants check box on all of the preceding tabs.
Select an object (such as a form, page, or table) directory.
Select the Unrestricted check box on the Read permission tab, but do not click Apply to this directory and all descendants.
Apply the same Read permission settings (as in Step 7) 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 (such as pages, forms, tables) within those directories.
Review individual objects to determine if the Require login for access option should be enabled.
For more information, see the chapter on deploying and distributing applications in the Programmer's Guide of the server's Classic Development Help.
If you choose the installation default, the SilverStream 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 SilverStream server is running in a restricted production environment, all users will be required to authenticate themselves when accessing the server.
If you did not chose the Restrict Access to the SilverStream Server installation option, your server resources are not locked down. If you are developing SilverStream applications, you may want to run the server in a unrestricted design environment until you are ready to deploy the application. Installing the SilverStream 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 SilverStream directory. A directory is a container for objects of one type; for example, all forms are in the Forms 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). Any new object takes on the access security of the immediate parent object. For example, if you create a new form in a SilverStream database, the form is saved in the Forms directory and takes on the security settings of the Forms directory.
During installation, SilverMasterInit creates two predefined groups (Administrators and Developers) and sets permissions for both groups. The server requires all users to login. Default group permissions for a locked down server are as follows:
Access to server administration operations is restricted to members of the SilverStream Administrators group. Access to administration resources (such as who can use the SMC, view session and statistical information, add and remove users and groups) is only granted to members of this group.
Developers can access design resources (directory listings) so they can use the SilverStream Designer. Developers, however, will not be able to add a database in the Designer until you allow access.
You typically separate who is allowed to read an object (that is, view design-time information) 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 SilverStream 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 which will enable them to log in and access any existing application 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 an application database, a server, and/or an entire cluster. Locking down these items helps secure your production and deployed application environment by making sure that the appropriate access permissions are set.
For example, when deploying an application, you might want to lock down the application database so no one can access it except you, then progressively unlock it as appropriate in the production environment.
CAUTION If, when you installed the SilverStream server, you did not choose the Restrict Access to the SilverStream Server 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:
Default server and object security describes default SilverStream server installation settings.
Using SilverCmd to lock down the server, an application, or a cluster.
Security checklist provides an important security overview.
Securing the development server 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. You would then 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. You should then set unrestricted Read access to the SilverMaster database to allow users (with appropriate permissions) to access other databases and log in to the server. Finally, to restrict retrieval access to the SilverMaster database from within SilverStream, restrict the Select permission to administrators at the Tables directory level and apply to all descendants.
For more detailed instructions, see
Step 9: Secure the SilverMaster database
.
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 applying the restriction to all descendants. Also, to restrict retrieval access to the database from within SilverStream, restrict the Select permission to administrators at the Tables directory level and apply to all descendants.
Included with the SilverStream server (in the SilverStreamInstallDir\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 in the Facilities Guide of the server's Core Help.
The secure_server_sample.xml input file shows you how to lock down an entire server.
You might want to apply this file to a server when putting it into production.
The secure_appication_sample.xml input file shows you how to lock down an application.
You might want to apply this file to an application database just before deploying it in order to secure it properly.
The secure_cluster_sample.xml input file shows you how to lock down a cluster.
You might want to apply this file after you have secured each server in a production cluster using secure_server_sample.xml.
The levels and types of security that 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 choose the installation default, the SilverStream 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 application objects 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 SilverStream server is installed behind any firewalls your company uses.
For more information, see
Server configurations.
Set up a unique database account for the SilverStream server to use to connect to each database.
For more information, see
Database 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, design, and administration ports. The server supports ports for the following three security protocols: HTTP, HTTPS-RSA, and HTTPS-DSA. 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 in SilverStream or can be obtained from an external security system. For SilverStream-defined entities, all information is stored in the SilverMaster database catalog. 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 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 an anonymous Web user's ability to access to your site, enter a 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) appears, your site is allowing anonymous access and you may want to complete the steps in one of the following procedures to require user authentication.
To require user authentication:
For more information, see
Enabling authentication.
SilverStream displays a directory listing when users request certain URLs from a browser or using the Designer. Although a listing of directory entries may not seem terribly critical to your site's security, you may still 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 appears:
You are not allowed to read the specified resource. Additional technical details about this error are available.
If an HTML directory list appears, you may want to disable the directory listing access as described in the following steps.
To check whether the non-HTML directory listing is enabled (and optionally disable it):
From your browser, enter a 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 appears:
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 need to disable directory listing access as described in the following steps.
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 SilverStream server 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.
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:.
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.
#Written by SilverStream Server #Mon Oct 16 19:08:36 EDT 2000 com.sssw.srv.fulltextsearch.noindexonsearch=false com.sssw.loadbalancer.connect.tryInterval=30 com.sssw.srv.server=SilverStream\ Server/4.0 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 as well as the password for each mail account the server connects to. 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.
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 application databases configured in 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 of the 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 application databases.
In Step 4 of that procedure, select the SilverMaster database that you think should be restricted. Select an object that is stored beneath the parent level of the directory structure of the SilverMaster database to test access.
To lock SilverMaster resources below the main directory level:
Open the SMC as an administrator and select the Security options.
In the left panel, select the SilverMaster database beneath 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.
In the left pane, expand the SilverMaster database and select the Tables directory.
Restrict Select access to members of the Administrators group and click the Apply to this directory and all descendants radio button.
Reselect the SilverMaster database and set unrestricted Read access.
Repeat steps 9 and 10 for each of the directories and subdirectories expanded beneath SilverMaster (such as Tables, Forms, Views, EJB JARs &Media, and Pages, General, Images, Jars, and Sounds).
For more information, see
The SilverMaster database catalog.
Restrict user access to application databases by setting permissions on directories and objects (such as pages, views, and business objects) using simple or advanced expressions.
Permission settings apply to the directory, all subdirectories, and 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 SilverStream 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. A directory is a container for objects of one type--for example, all forms are in the Forms 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 a page (or other object) that you think should be restricted that is stored beneath 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 EJBs, 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.
Many of guidelines in the preceding checklist also apply to securing the development server. For example, you can use secure communications between the SilverStream server and Java clients such as the SilverStream Designer and SMC through a DSA certificate.
To secure your development server:
Add your developers to the Developers group and restrict access to this group as described in the following steps.
(Optional) Configure a separate port for use by your developers.
Restrict any objects from specific developers as needed. You can do this at the server, cluster, or object level. You need to be logged in to the server as an administrator with the Locksmith privilege.
You can require login for forms, tables, views, and pages by activating Require login for access.
Secure access by directory or object type, for example:
The Tables directory, allowing Write access only to designated database developers
The Form, View, and Pages directories, allowing Write access only to developers
The Objects directory, allowing Write access only to designated business object developers
The ability to write a business object is like "superuser" access. A business object can bypass other SilverStream security and shut down the server or otherwise compromise data.
The Media directory and its subdirectories, allowing Write permissions only to developers
For more information, see
Authorization and access control and
Ways to lock down a server.
|
|
Administrator's Guide |
Copyright © 2001, SilverStream Software, Inc. All rights reserved.
