Chapter 47
Security Service Configuration

 

 

This chapter describes configuring security for your clients and servers. Most configuration is done at the partition-level. To set any of these properties or edit the configuration files discussed in later chapters, you use the Console. In the Navigation Pane, right-click on the node of interest (a partition, client, or even a server itself) and select "Edit Properties" from the context menu. You may then select the appropriate security tabs and provide your security information.

Configuring Clients

---

There are two types of clients to consider. The first type, AppClients, use XML files to specify their configuration. You will need to edit these XML files directly using the DDEditor or another editing tool in order to configure these types of clients.

The Console supports the configuration of VisiBroker clients--that is, clients whose security is managed by the server's ORB and whose properties are persisted there.

In either case, the steps necessary to configure security are the same.

Step One: providing identities

---

You set up your client's identities by editing its configuration file. You set the location of this file by using the console to set

vbroker.security.authentication.config

to the path of the configuration file for the client. Once that is done, you may edit its contents from the Console and supply LoginModules to collect and/or provide client identities to the server's realms. See the next chapter, "Authentication," for detailed information on the contents and grammar of this file.

Step Two: set up the callback handler

---

You specify a callbackHandler object to obtain authentication information from the Client when a server requires it. For AppClients, there is a special XML tag that is used to specify the callbackHandler. For other clients, you simply use the setCallbackHandler API to specify the callbackHandler object to use or specify it in the Console. Refer to "Security API and Property Reference" in the Borland Enterprise Server Programmer's Reference for details on using the API.

Step Three: set up the client-side quality of protection

---

This is performed for Java clients only. You use the ClientQoPConfig API s to set up trust relationships between clients and servers and transport policy. This policy can also be set via the Console. Refer to "Security API and Property Reference" in the Borland Enterprise Server Programmer's Reference for details on using these APIs.

Step Four: login

---

You login upon successfully authenticating your client to the server. Logging in can take place programatically using the login() method of the com.borland.security.Context interface. Refer to "Security API and Property Reference" in the Borland Enterprise Server Programmer's Reference for details on using this interface.

Configuring Servers

---

Configuring servers involves many of the same steps to configuring clients, but adds the concepts of configuring authentication realms and authorization domains for clients.

Step One: providing identities

---

You set up your server's identities by editing its configuration file. You set the location of this file by using the Console to set

vbroker.security.authentication.config

to the path of the configuration file for the server or partition. Once that is done, you may edit its contents from the Console and supply LoginModules to collect and/or provide server identities to the host realm. See the next chapter, "Authentication," for detailed information on the contents and grammar of this file.

Step Two: set up authentication realms

---

In the server's authentication configuration file, you also include entries for the various authentication realms that clients authenticate against, and populate these entries with appropriate LoginModules. See the next chapter, "Authentication," for detailed information on how this is done.

Step Three: set up authorization domains

---

Each Role DB file is associated with its own authorization domain. An authorization domain is a security context that uses a defined Role DB file (see below, Step Four) to set authorization permissions. EJBs can be deployed to multiple security contexts with different permissions and roles. Authorization domains are set with VisiBroker ORB properties in the Console. See the "Authorization" chapter, below, for detailed information on authorization domains.

Step Four: set up authorization roles

---

Borland Enterprise Server uses an access control scheme based on "roles." The deployment descriptor maintains a list of roles that are authorized to access each enterprise bean method. The Borland Security Service uses a role database (Role DB) --a file whose default name is roles.db--to do the association between user identities and EJB roles. Each authorization domain has its own Role DB file, the location of which is specified by setting properties in the Console. See the "Authorization" chapter, below, for detailed information on setting up Role DBs.

Step Five: set up the callback handler

---

You specify a callbackHandler object to obtain authentication information from a client when a server requires it. You use the setCallbackHandler API to specify the callbackHandler object to use or specify it in the Console. Refer to "Security API and Property Reference" in the Borland Enterprise Server Programmer's Reference for details on using the API.

Step Six: set up the server-side quality of protection

---

You use the ServerQoPConfig API s to set up trust relationships between clients and servers and transport policy. You also specify an AccessPolicyManager interface to coordinate between your Role DBs and your POA objects. This policy can also be set via the Console. Refer to "Security API and Property Reference" in the Borland Enterprise Server Programmer's Reference for details on using these APIs.

Step Seven: login

---

You may login in one of two ways. You may set up the server to automatically log in at ORB-init time by setting the vbroker.security.authentication.login property to "true" in the console.

If you prefer, you can set this property to "false" and login programatically. You may call the login() method of com.borland.security.Context and login using either the system JAAS information, a wallet, a generated Vault, or a CallbackHandler. Refer to "Security API and Property Reference" in the Borland Enterprise Server Programmer's Reference for details on using the API.