cq9怎么玩容易进免费旋转

書名： IBM WebSphere Application Server v7.0 Security
作者名： Omar Siliceo
本章字數： 1280字
更新時間： 2021-04-09 22:02:55

Chapter 2. Securing the Administrative Interface

Did your parents, or other adults, ever tell you when you were a child, "make sure you lock the door when you leave the house"? Why was that? Normally, you have a lock on the front door so only those persons who have the correct key can get in the house. I say normally, because there may be people out there like my late grandfather in-law, who used to live in a small town in Tennessee. He would keep his house locked while he was at home and would keep it unlocked when nobody was home in case a relative or friend would need to go inside his home. The same applies to your WebSphere Application Server (WAS ND7) infrastructure. Not having a secured administrative interface (that is, having global security disabled) is equivalent to your house having a front door without a lock.

Out of the box, there is no security enabled. Why? IBM gives the freedom to use whatever user registry infrastructure is already used by your company. Such registry will contain a list of users and groups they belong to. Access to WebSphere resources will be granted by user ID and user groups defined in the registry.

This chapter describes the following topics:

Concepts surrounding the WebSphere web-based administrative interface
How security affects the overall WebSphere infrastructure
Presents the pieces of information that required to secure the administrative interface
A procedure to follow in order to secure the WebSphere global administrative infrastructure.

Information needed: Planning for security

Continuing our analogy, if you want to secure your front door, you need to know what tools and parts you will need to install a lock. Similarly, in order to implement global security for your WebSphere environment, we need to figure out what is needed to enable it and what procedure to follow to accomplish this task. Therefore the purpose of this major section is to identify possible values and sources for the parameters that are required throughout the Enabling security section. Consequently, there may be a need in the rest of this chapter to reference the table in the following subsection "The LDAP and security table", that summarizes this chapter's required parameters and values. So, it may be a good idea to place a bookmark on the page where the table starts for easy reference.

Note

In order to simplify references from the rest of the chapter to the table presented at the end of this section, it will be denoted as the LDAP and security table.

The type of information required to enable the administrative security varies. It will depend on the type of user registry. Most medium to large corporations would use a type of user registry based on LDAP as the underlying technology. Therefore, in this book, we will be using LDAP as our underlying user registry technology. LDAP stands for Lightweight Directory Access Protocol. Describing the LDAP technology itself is out of the scope of this book, as it would take a whole other book to describe it. However, in the next few paragraphs it will be highlighted along with the elements of LDAP-based registries that are needed in our task of enabling the administrative security, focusing on the values that can be used with each parameter. If you are interested in further exploring the concepts behind the LDAP technology, you can start with the book "Understanding LDAP", by IBM, available online at: http://www.redbooks.ibm.com/redbooks/SG244986/wwhelp/wwhimpl/js/html/wwhelp.htm. In addition, a description for each of the parameters is readily available from the LDAP configuration page, available by following the breadcrumb Security | Global security | Standalone LDAP registry.

Note

For all practical purposes, enabling the administrative security of WebSphere is equivalent to enabling WebSphere global security. Those terms will be used interchangeably in this book.

Tip

Best practice: Gather required information beforehand

Use the table provided next as an information template of data that needs to be collected before starting the process of enabling security. For instance, for each of your cells, create a spreadsheet which summarizes the required data.

The LDAP and security table

For LDAP-based global security configuration, you will need to gather the following parameters:

SSO domain name:

This refers to the LDAP realm. It is the common DNS domain shared across multiple applications. SSO stands for single sign-on. An example of SSO domain name would be the top portion of your domain name: yourcompany.com, which is the value to be used for this parameter.

WebSphere administrative identity and password:

This is an ID that already exists in the LDAP registry and which will be used to log in to the WebSphere Console (or more precisely, the Integrated Solutions Console) once global security is enabled. For our examples throughout this chapter, we will use the ID wasadm.

Server user identity and password:

This will be the primary administrative ID for intercommunication within the WebSphere cell. Infrastructure WebSphere components, such as the deployment manager and node agents, will present these credentials to communicate with each other. We will use the ID wasadm also. Since this parameter is only available when the Server identity that is stored in the repository option is selected, just like the other IDs, the ID used for server user identity must already exist in the LDAP repository.

Bind distinguished name and password:

This ID must exist in the LDAP registry. It is the ID that WebSphere uses to connect to and authenticate with the LDAP registry. The major requirement for this ID is that it must have read privileges to users and groups under the LDAP domain. Specifically, it should be able to read starting at the LDAP base distinguished name. (See below for additional information.) This ID must be entered in an LDAP distinguished name format. We will use: uid=wasbind,ou=service,o=yourcompany.com.

Server user ID

This ID must exist in the OS. It is the ID that will own the deployment manager process. We will use the value wasid.

LDAP server Host name:

The fully qualified domain host name of the LDAP server. We will use the value jsdsdev01.yourcompany.com.

LDAP server TCP port:

It is the TCP port to which the LDAP server is listening. (Verify with your LDAP team whether WebSphere should use plain or SSL protocol.) We will use the standard LDAP un-encrypted port, 389.

LDAP base distinguished name:

Obtain this information from your LDAP administration team. We will use the value: o=yourcompany.com. Unless your environment uses multiple DNS domain names, yours may be similar to the one we are using. When selecting this value, extreme care must be taken to insure that the value selected, which is the root of all WebSphere LDAP queries, does not include branches that won't return any results. In other words, select this value to avoid global searches and only focus on the branches with the subset of users and groups that will be accessing the applications hosted in the WebSphere environment.

URL to the Integrated Solutions Console:

URL you normally use to access your deployment manager console.

Tip

Best practice: Personal WebSphere Administration IDs

When more than one person will be sharing the responsibilities of administrating a WebSphere environment, it is customary to define each user with the role of Administrator. In this way, a single ID could be used for the WebSphere administrative ID and server ID, reducing the overhead of having multiple IDs. In essence, you are reserving the administrative ID for operational use only.

Your LDAP administrator should be able to provide you with the appropriate distinguished name for your bind ID. As a prerequisite to enabling security, it is likely that you will need to request the LDAP team to create this ID.

官术网_书友最值得收藏!

IBM WebSphere Application Server v7.0 Security

Note

Note

Tip

Tip