WebSphere Application Server has good security support. Security is simply to determine who has access to important system resources, including files, directories, programs, connections, and databases. Running WebSphere application servers in standalone mode is more secure than running as part of a WEB server. If the security requirements exceed the security provided by the WEB server, run the WebSphere Application Server in standalone mode. The following describes the use of access control tables to protect resources, select authentication schemes and protocols, and use directory services in WebSphere application servers.
- 1. Protecting resources with access control lists
Establishes a basic process for setting up security.
Security-related concepts include users, groups, resources, permissions, domains, and access control lists (ACLs), which are closely related and are described below:
(1) User: An identity that can be authenticated by the WEB server. A user can be a person or a computer.
(2) Group: A collection of users. Groups provide an effective way to manage a large number of users, because administrators can specify the permissions of a group at a time. Typically, there are some common characteristics among group members. For example, a company might include a group of management-level employees, and another group of non-administrative employees. Where a non-administrative user may be given access to view sales data files, and administrative users are given access to view and edit sales data files. You can define a person as a single user and also define it as a member of a group. For example, a personal Amy may represent a single user, Amy, or a member of the group managers.
(3) Resources: valuable resources that are accessed through a Web server include HTML files and directories (Web pages), other files and directories (such as FTP files), Web applications (Java Servlet or CGI programs), Resources accessed through WebSphere application servers include Java Servlets, custom servlets that enable access to enterprise resources and applications (such as databases), connections, sockets, files, and other resources that can be used by servlets.
(4) Permission: The permission represents the privilege of requesting access to the resource. Administrators can grant permissions to users and groups by establishing access control lists to protect resources. Permissions are related to a specific resource. Imagine if a user has permission to view file A and modify file B. Then the user cannot modify file A with permission to modify file B. Each license is applicable only to specific resources and cannot be passed. A single user's permissions take precedence over the group's permissions. For example, if a user Amy has read and write rights to a file, but at the same time that the group to which Amy belongs has only read access to the file, Amy still has read and write rights to the file because a single user's permission overrides the more qualified group permissions. (even if the group's permissions are less restrictive than the individual user's permissions, the user's permissions will still override the group's permissions).
(5) Domain: The domain is a database of users, groups, and access control tables. In order for users to access resources in the domain, users who need access to the resources must be defined in that domain. A user can belong to several domains, but the user identifier cannot be duplicated in the same domain. For example, a user Amy can belong to the Filerealm and Anyrealm domains. However, only one user named Amy can be included in each domain. Each domain gives the user a different license to access different resources.
(6) Access Control table: the Access control table associated with the resource specifies which users and groups in the domain can access the resource.
The relationship between access control lists (ACLs), domains, and resources is as follows:
L One domain can contain many ACLs.
L One domain can contain many resources.
L an ACL can belong to only one domain.
L A resource can belong to only one domain.
L A resource is associated with only one ACL.
L an ACL can be associated with many resources.
WebSphere Application Server comes with some pre-established areas:
L Defaultrealm defines how users can access locally defined resources. Access control tables can also be established to determine which users and groups
Which resources have access to.
L NT Domain (ntrealm) and UNIX domains (Unixrealm) Define how users with accounts in the operating system can use
WebSphere Application Server resources. Users defined in the operating system can be shared by WebSphere application servers. Such sharing persists as long as they exist in the underlying system. The WebSphere Application Server Manager interface enables you to view the domain, but to change it, you must use the facilities provided by the operating system. Currently, WebSphere application servers can share operating system-defined users, but they cannot share groups.
L Servletmgrrealm defines how the servlet accesses remote-defined resources, such as a remotely mounted servlet. Servletacl is
The only access Control table in the field. When a remote mounted, digitally signed Servlet tries to access a protected resource, the digital certificate in the servlet is compared to the digital certificate in Servletmgrrealm that is associated with the user. SERVLETACL defines whether permission is granted or denied. For example, assume that a digital certificate for user X is encapsulated in a Anyservlet.jar file. If user X is added to Servletmgrrealm, all Servlets (anyservlet.jar files) that contain the same digital certificate as that user can execute and access the resources assigned to that user.
Finally, if the directory service is enabled in the Directory Management page of WebSphere Application Server Manager, the
Ldaprealm. WebSphere application servers can share users and groups defined in the directory service, and the share will persist until they are removed or directory management support is disabled. The WebSphere Application Server Manager interface enables you to view the realm, but to make changes to it, you must use the facilities provided by the LDAP server. For more information about LDAP, directory services, and Ldaprealm, see the documentation for working with directory services.
The WebSphere Application Server allows you to set various licensing rights. For example, this includes permissions to send and receive files, delete files, read and write files, Mount Servlets, link to library files, open and listen to sockets, and so on. In some cases, the service does not require its customers to exist in the access control table. For example, many Web page (HTTP) services expose their documents to all users without requiring them to register in the Access control table.
This resource can be secured by establishing a single access control list (ACL) for each resource in a single domain (discussed below). The ACL specifies the user or group that can access or modify the resource. For each resource to be protected, you need to specify the access control table, security realm, authentication scheme (the method used to authenticate the user accessing the resource). An example of implementing security is described below.
The basic steps for using the various Manager pages to establish security with access control lists are shown below.
(1) define the user.
Use the Users page to define users using security, which defines the individuals and computers that are allowed access to the resource. For example, define a user named Bopeep:
L Select Defaultrealm.
L Click the Add button at the top left of the page.
L Enter the username bopeep.
L Enter password sheep. Enter the password again for verification.
L Click the OK button.
L Verify that Bopeep is displayed in the Defined Users list.
(2) Optionally define groups
Use the Groups page, using security, to define the groups to which users belong, making administration easier. First, select an area. Next, choose to add the group to the realm. You can name groups with your favorite names, and then convert users from non-member States to Member States. For example, add the user bopeep to the group Mypeeps:
L Select Defaultrealm.
L Click the Add button at the top left of the page.
L Input Group name Mypeeps.
L Select User Bopeep in the "Non-member" list.
L Click the Add button next to the non-members list.
L Verify that Bopeep has been converted to the member box.
(3) Creating ACLs
Use the Access Control tables page to create ACLs using security. For example, create an ACL named Sheepcontrol:
L Click the Add button next to the Define access control list.
L input ACL name Sheepcontrol.
L Click the OK button.
(3) Defining resources
Use the Resources page, using security, to add the resources you want to protect into your domain. (Note: You must perform the "Create ACL" step before you can perform this step because you must specify the ACL to which the new resource belongs.) For example, add the Checkmessage Servlet to the Sheepcontrol ACL in the realm Defaultrealm:
L Select Defaultrealm.
L Click the "Add" button.
L Select the basic scheme as the authentication scheme. (The scenario option is discussed below).
L Select the Sheepcontrol ACL.
L Select the servlet and specify the Checkmessage servlet.
L Click the OK button.
L Verify that Checkmessage is now listed as a resource for ACL Sheepcontrol.
(4) Granting of license rights
Returns ACLs and gives users, groups, and computers permission to access ACL resources. For example, give Bopeep a GET and PUT permission so that it can access files and folders in the realm Defaultrealm Sheepcontrol ACLs:
L Ensure that Sheepcontrol is selected in the Defined Access Control list box.
L Click the Add button next to the main permission field at the bottom of the page.
L when the "ACL Sheepcontrol Add Permissions in Defaultrealm" box is displayed, click Files and folders.
L Next, select the license option to Bopeep. Because Bopeep is a user, click Users. In the list, select
Choose Bopeep. (Note that if you select group, you will see the group Mypeeps in the main name list).
L Use check boxes to give Bopeep a GET and PUT permission.
L Click the OK button.
L Verify that the Bopeep has the correct permissions by reviewing the Master Permissions box. If you do not see the permissions, click Bopeep
The plus sign on the left. A list is displayed that shows the permissions for the Bopeep.
- 2. Select authentication schemes and protocols
The first discussion is about authentication protocols, HTTP and HTTPS. The next discussion will be on the certification scheme, which is basic, digest, custom, and certificate authentication. The final discussion is about strategies for combining scenarios and protocols.
(1) About the certification agreement
HTTPS is a combination of HTTP and SSL protocols. SSL (Secure Sockets Layer) is a network security protocol that is used to provide the necessary security between a server and a client. If you choose HTTP, the receipt of the authentication data is not protected. If you choose HTTPS, the authentication data is encrypted in each SSL protocol. If you want to use certificate authentication, you must use HTTPS.
(2) About the certification scheme
WebSphere Application Server Support Certification Scheme includes Basic authentication, Digest authentication, custom authentication, certificate authentication.
Basic authentication: Use HTTP or HTTPS to request the user name and password from the client. Using plain text will be used to verify the
The information is sent to the server for verification. Basic authentication is supported for all browsers. If a user identifier and password provide sufficient authentication, consider using Basic authentication.
L Digest Authentication: Requests the user name and password from the client using HTTP or HTTPS. The user name and port that will be used for authentication
Sent to the server using the encryption form (use summary). Digest authentication is not supported in all browsers. (currently only the Sun HotJava browser supports this authentication scheme.) If the browser does not support digest authentication, its users will not be able to access resources protected by the Protocol.
L Custom Authentication: Use HTTP or HTTPS to request client information that is customized using HTML format. by CGI and
The Servlet sends the information that is used for authentication to the server using plain text. Custom authentication can be used when user authentication is required in addition to identifiers and passwords. For example, you can request a user authentication for a social security number. Using this protocol, you can create an HTML format to ask for user data. Authentication is performed by server-side code (CGI and Servlet), not by the IBM WebSphere Application Server Runtime application. If you use custom authentication, use HTTPS to protect your data.
L Certificate authentication: Use HTTPS to request a client certificate. The SSL client authentication option must be enabled. will be used to verify
Send the information to the server. The digital certificate used for authentication is highly secure, and certificate authentication is usually transparent to the user. The client certificate is managed by the system or site administrator. Typically these tasks are licensed by the Certificate Authority Server software, such as the IBM Vault Registry product.
(3) Combination authentication scheme and protocol
As mentioned earlier, HTTPS is generally preferable unless it is in a security-agnostic environment. Scenarios and protocols can be combined for different security requirements, with the following policy:
• For basic security requirements, use custom authentication on Basic, digest, or HTTP.
L Use custom authentication on Basic, digest, or HTTPS for higher security requirements.
• For the highest security requirements, use certificate authentication on HTTPS.
- 3. Using Directory Services
A directory service is a combination of information warehousing, access methods, and related services. Information warehouses are typically databases that store location information and details about other resources, such as users, printers, file servers, and WebSphere application servers. Accessor means a Lightweight Directory Access Protocol (LDAP) or other access method that can be used to communicate with directory service components. Related services are facilities provided by the directory service for querying, manipulating, and authenticating information in the database.
The use of directory services is typically required for centralized security data. Directory services can provide a single point of management for the entire network. With the directory service, you can define users and groups for all applications, including WebSphere application servers at once, without having to define users and groups separately for each application. Directory services are useful for security by authenticating users and controlling access to resources. Without a directory service, you may have to duplicate the same users and groups for different software products, such as WebSphere application servers, WEB servers, and operating systems, because these software products do not share security data.
WebSphere Application Server version 2.0 supports directory services that use Lightweight Directory Access Protocol (LDAP) V2. These directory services include Domino directory version 4.6.x and Netscape directory Server version 3.x. WebSphere Application Server version 2.02 (native language version) also supports the Enetwork Directory components of IBM Suites (not including IBM Suites version 1.0). The basic steps for using directory services are as follows:
(1) Set up the directory service, or use an existing directory service.
(2) Use the Directory Management page of the manager interface of the WebSphere application server to identify to WebSphere app service
Directory service and specify the basic settings.
(3) View directory service user and group information in Manager.
(4) Define access control tables (or existing ACLs) in the WebSphere application server to take advantage of directory service user and group information.
(5) Protect WebSphere Application server resources with ACLs.
To specify a directory service using the Directory Management page, follow these steps:
• View the "Settings" page, "Directory Management".
In the "Configuration" tab, in the "Do you want to enable the directory?" field, click Yes
L Use the drop-down list to select the directory type. Choose:
¾ " Netscape "using Netscape Directory Server;
¾ "domino4.6" uses Domino Server;
¾ "Enetworkibmsuite" uses IBM Suite's enetwork Directory Server components.
L Enter the host name of the computer hosting the directory service.
L Enter the port number of the service.
Enter the base DN of the LDAP search starting point that will be the directory service. For example, o=raleigh.ibm.com.
L Optional function. Enter a union resolution name and a union password. These field blanks represent the WebSphere Application Server anonymous directory
Service. If you specify a co-resolution name and password, verify that the directory service is configured to use the same distinguished name and password to authenticate the WebSphere application server, or the authentication will fail.
When you use directory management to specify a directory service, the features that the manager will provide are:
L dynamically establish, initialize, and maintain the ldaprealm associated with the LDAP directory service.
l Use the Security page of the manager to correlate WebSphere Application server resources and Ldaprealm.
L Associate WebSphere Application Server access control lists (ACLs) with Ldaprealm resources.
Idaprealm is a WebSphere Application server security area that contains users and groups that have been defined in the directory service. You can use the Security page of the manager interface of the WebSphere Application server to establish an association between the access Control table and the Idaprealm. Ldaprealm protects resources, and access control lists allow users and groups belonging to that domain (in this case, users and groups in the directory service) to access resources.
Ldaprealm uses a non-SSL LDAP V2 protocol to communicate with the directory service and is linked according to the settings specified in the Directory Management page. When a WebSphere Application Server resource protected by Idaprealm requires authentication, the client's user identifier and password are validated against Idaprealm. The process is as follows:
The client sends a Servlet request to the WebSphere application server.
The WebSphere Application server determines whether the requested resource is protected by ACLs.
L therefore WebSphere Application server sends an authentication request to the client.
L The client enters the user identifier and password.
The directory service verifies that the user identifier and password match the Idaprealm of the protected resource: The directory service issues an LDAP check
To find the person that matches the specified user identifier. Create a distinguished name (DN) for the user.
The directory service performs an LDAP connection using the user distinguished name and password.
When the directory service authenticates the user, the WebSphere Application Server Java engine invokes the Servlet to handle the
Client requests that have consistent permissions.
You can test whether the directory service is running by accessing ldap://act:389/o=raleigh.ibm.com: Act is the hostname of the machine running the directory service, 389 is the port number of the service, and o=raleigh.ibm.com is the base distinguished name, It also represents the search starting point in the directory service.
websphere--Security
