27.1. Main Data StructuresTo understand the code for the neighboring infrastructure, we first need to describe a few data structures used heavily in the neighboring subsystem, and see how they interact with each other. Most of the definitions for these structures can be found in the file include/net/neighbour.h. Note that the Linux kernel code uses the British spelling neighbour for data structures and functions related to this subsystem. When speaking generically of neighbors, this book sticks to the American spelling, which is the spelling found in RFCs and other official documents.
The neighboring code also uses some other small data structures. For instance, struct pneigh_entry is used by destination-based proxying, and struct neigh_statistics is used to collect statistics about neighboring protocols. The first structure is described in the section "Acting As a Proxy," and the second one is described in the section "Statistics" in Chapter 29. Figure 27-2 also includes the following data structure types, described in greater detail in Chapters 22 and 23: Figure 27-1. Relationship among dst_entry, neighbour, and hh_cache structures
Figure 27-2 shows the relationships between the most important data structures. Right now it might seem a big mess, but it will make much more sense by the end of this chapter. Here are the main points shown in Figure 27-2:
|
Tuesday, October 20, 2009
Section 27.1. Main Data Structures
10.2 Conditional Compilation
| I l@ve RuBoard |
10.2 Conditional Compilation
Through the use of conditional #ifdef DEBUG
If the beginning of the program contains the following directive, the #define DEBUG /* Turn debugging on */ If the program contains the following directive, the #undef DEBUG /* Turn debugging off */ Strictly speaking, the #undef DEBUG is The directive #ifndef causes the #ifndef STACK_SIZE /* Is stack size defined? */ #else reverses the sense of the #ifdef DEBUG A programmer may wish to temporarily remove a section of code. A /***** Comment out this section This generates a syntax error for the fifth line. Why? Because the */ **** End of commented out section */ is not a legal C++ statement. A better method is to use the #ifdef #ifdef UNDEF (Of course the code will be included if anyone defines the symbol The compiler switch CC -DDEBUG -g -o prog prog.cc compiles the program prog.c and includes all the bcc32 -DDEBUG -g -N -eprog.exe prog.c The general form of the option is -Dsymbol or CC -DMAX=10 -o prog prog.c Most C++ compilers automatically define some system-dependent
|
| I l@ve RuBoard |
Chapter 8. Process Control
Chapter 8. Process Control
Exercises |
Section 26.11. Data Areas
26.11. Data AreasApplications often need to read or store data. Depending on the use case, this data may be stored in one of many locations. Consider preferences as an example. Typical products use at least some preferences. The preferences themselves may or may not be defined in the product's plug-ins. For example, if you are reusing plug-ins from different products, it is more convenient to manage the preferences outside the plug-in. In addition, applications often allow users to change preference values or use preferences to store recently opened files, recent chat partners, and so on. These values might be stored uniquely for each user or shared among users. In scenarios where applications operate on distinct datasets, some of the preferences may even relate to the particular data and should be stored or associated with that data. Preferences are just one example, but they illustrate the various scopes and lifecycles that applications have for the data they read and write. Eclipse defines four data areas that capture these characteristics and allows application writers to properly control the scope of their data:
In addition to these Eclipse wide areas, the Runtime defines two locations specifically for each installed plug-in:
Each of these locations is controlled by setting the system properties described before Eclipse starts (e.g., in the config.ini). Locations are URLs. For simplicity, file paths are also accepted and automatically converted to file: URLs. For better control and convenience, there are also a number of predefined symbolic locations that can be used. Note that not all combinations of location type and symbolic value are valid. Table 26-1 details which combinations are possible.
Since the default case is for all locations to be set, valid, and writable, some plug-ins may fail in other setups, even if they are listed as possible. For example, it is unreasonable to expect a plug-in focused on instance data, such as the Resources plug-in, to do much if the instance area is not defined. It is up to plug-in developers to choose the setups they support and design their functions accordingly. Note that each of the locations can be statically marked as read-only by setting the corresponding property osgi.AAA.area.readonly=true, where "AAA" is one of the area names. |
Recipe 11.11. Configuring Actions to Require SSL
Recipe 11.11. Configuring Actions to Require SSLProblemYou want to control if HTTPS is required on a page-by-page basis. SolutionUse the SSLEXT Struts extension. DiscussionThe Struts SSL Extension (SSLEXT), an open source Struts plug-in, SSLEXT enables fine-grained secure protocol control by
The SSLEXT distribution consists of a plug-in class for
For JSP pages, SSLEXT provides custom extensions of Struts tags for SSLEXT works by intercepting the request in its You can download the SSLEXT distribution from the project web site.
Make the following changes to the
If you have accessible JSP pages you want to specify as secured (or <%@ taglib uri="http://www.ebuilt.com/taglib" prefix="sslext"%> Now rebuild and deploy the application. When you click on a link to a
You can use SSLEXT alongside container-managed <security-constraint> You can then use SSLEXT for fine-grained control of the protocol at See AlsoEnabling an application server to support https SSLEXT is hosted on SourceForge at http://sslext.sourceforge.net. Craig McClanahan presents a good argument against switching back to Recipe 11.9 shows how you can specify the |
Section 3.5. Prototype
3.5. Prototype
Every object is linked to a prototype object from which it can inherit properties. All objects created from object literals are linked to Object.prototype, an object that comes standard with JavaScript.
When you make a new object, you can select the object that should be its prototype. The mechanism that JavaScript provides to do this is messy and complex, but it can be significantly simplified. We will add a beget method to the Object function. The beget method creates a new object that uses an old object as its prototype. There will be much more about functions in the next chapter.
if (typeof Object.beget !== 'function') {
Object.beget = function (o) {
var F = function () {};
F.prototype = o;
return new F();
};
}
var another_stooge = Object.beget(stooge);The prototype link has no effect on updating. When we make changes to an object, the object's prototype is not touched:
another_stooge['first-name'] = 'Harry';
another_stooge['middle-name'] = 'Moses';
another_stooge.nickname = 'Moe';
The prototype link is used only in retrieval. If we try to retrieve a property value from an object, and if the object lacks the property name, then JavaScript attempts to retrieve the property value from the prototype object. And if that object is lacking the property, then it goes to its prototype, and so on until the process finally bottoms out with Object.prototype. If the desired property exists nowhere in the prototype chain, then the result is the undefined value. This is called delegation.
The prototype relationship is a dynamic relationship. If we add a new property to a prototype, that property will immediately be visible in all of the objects that are based on that prototype:
stooge.profession = 'actor';
another_stooge.profession // 'actor'
We will see more about the prototype chain in Chapter 6.
22.10 ''Virtual'' methods
| [ Team LiB ] |
22.10 Virtual methodsThe keyword virtual Except in the case of a destructor, corresponding virtual functions have the same name. You don't put the word virtual But, in order to make our code more readable, when we derive off child classes from a parent class with a virtual function, we usually do put virtual One slightly weird thing is that a parent class destructor like ~cProgrammer() The delete
One final point should be mentioned here. Ordinarily, when you have a method virtual void somemethod()
But in the case of a virtual
|
| [ Team LiB ] |
Hour 20
Hour 20
| 1: | While your application is running and a connection has been made to a data source, what happens if you delete the data source from the file system while you are navigating records? What about inserting or deleting records? |
| A1: | Nothing happens. The database file is not locked, so you can delete it. You can add and delete records because you are just interfacing with a DataSet. However, once you attempt to update the data source with the new DataSet, an exception will be thrown because the file cannot be found. |
| 2: | Do you need a database to create datasets, tables, and records within the .NET Framework? |
| A2: | No, you can create an entire database during runtime using the .NET Framework classes. |
| 3: | What is a table relationship and how is it handled within a DataSet? |
| A3: | A table relationship is an association of two tables in a parent-child relationship. Table relationships are contained within the DataRelationCollection object in the DataSet. |
| Top |
14.2 Bitmap Fonts
[oR] 14.2 |
| < BACK NEXT > |
Section 19.1. Presentations
19.1. PresentationsThe Workbench uses the term presentation to define the set of Workbench classes that is responsible for managing and displaying editors and views. Presentations do more than paint widgetsthey are not just skins for the application. They also provide behavior for widgets. Presentations control the look of tabsthe very fact that tabs are used at allas well as toolbars, menus, and how parts are dragged from place to place. Presentations manage stacks of presentable parts such as views and editors. They allow collections of like parts to be stacked together and control the presentation and behavior of the stack. The Workbench may instantiate several presentations for a given page depending on the perspective layout. In essence, each hole that you define in your perspective is filled with a presentation that stacks views or editors in the hole. Figure 19-1 shows what Hyperbola would look like if you could remove all presentations from the Workbench. This isn't a mock-up; it is using a presentation that does not do much. The look resembles a perspective in which all views and editors are standalone. The most obvious quirk is that the chat editors and Console views no longer show their tabs. From the example, you can see that presentations play an important role in the Workbench and in defining the overall look and feel of your application. Figure 19-1. Hyperbola without a presentation |
Section 14.9. Related Modules
14.9. Related ModulesIn Table 14.9 you will find a list of modules other than os and sys that relate to the execution environment theme of this chapter.
|
Dreamweaver MX-PHP Web Development
| ||||||||||||||||
3.9 Declarative Security Policies
< Day Day Up > |
3.9 Declarative Security PoliciesSecurity policies associated with URIs and enterprise beans include the following:
Such authorization and delegation policies can be specified declaratively within the relevant deployment descriptors. 3.9.1 Login-Configuration PolicyAuthentication is the process of proving the identity of an entity. Authentication generally is performed in two steps: (1) acquiring the authentication data of a principal and (2) verifying the authentication data against a user (principal) registry. J2EE security authenticates a principal on the basis of the authentication policy associated with the resource the principal has requested. When a user requests a protected resource from a Web application server, the server authenticates the user. J2EE servers use authentication mechanisms based on validating credentials, such as digital certificates (see Section 10.3.4 on page 372), and user ID and password pairs. Credentials are verified against a user registry that supports the requested authentication scheme. For example, authentication based on user ID and password can be performed against an LDAP user registry, where authentication is performed using an LDAP bind request. A Web server is responsible for servicing HTTP requests. In a typical J2EE environment, a Web server is a component of a J2EE WAS. In this case, the WAS hosts servlets, JSP files, and enterprise beans. The login�authentication�configuration is managed by the WAS, which drives the authentication challenges and performs the authentication. Similarly, if the Web server is independent of the WAS and the Web server is the front end for the WAS, the Web server acts as a proxy for J2EE requests. Again, the authentication is typically performed by the WAS. The authentication policy for performing authentication among a user, a Web server, and a WAS can be specified in terms of the J2EE login configuration elements of a Web application's deployment descriptor. The authentication policy can specify the requirement for a secure channel and the authentication method.The requirement to use a secure channel when accessing a URI is specified through the user-data-constraint descriptor. The authentication method is specified through the auth-method element in the login-config descriptor. There are three types of authentication methods:
3.9.1.1 Authentication Method in Login ConfigurationThe auth-method element in the login-config element specifies how a server challenges and retrieves authentication data from a user. As noted previously, there are three possible authentication methods: HTTP (user ID and password), form based (user ID and password), and certificate based (X.509 certificate). With the HTTP authentication method, the credentials provided by the user consist of a user ID and password pair, transmitted as part of an HTTP header. When HTTP authentication is specified, a user at a Web client machine is challenged for a user ID and password pair. The challenge usually occurs in the following way:
With HTTP authentication, a realm name also needs to be specified. Realms are used to determine the scope of security data and to provide a mechanism for protecting Web application resources. For example, a user defined as bob in one realm is treated as different from bob in a second realm, even if these two IDs represent the same human user, Bob Smith. Once specified, the realm name is used in the HTTP 401 challenge to help the Web server inform the end user of the name of the application domain. For example, if the realm is SampleAppRealm, the dialog window prompting the user for a user ID and password pair during authentication will include that the user ID and password are to be supplied for the SampleAppRealm realm. HTTP authentication can be either basic or digest. In basic authentication, the credentials requested of the user are user ID and password, and both are transmitted as cleartext. In order for the authentication method to be basic, the auth-method element in the login-config descriptor must be set to BASIC. Listing 3.4 is a deployment descriptor fragment showing an example of login configuration requiring basic authentication. Listing 3.4. Login Configuration for Basic Authentication
This scheme is not considered to be a secure method of user authentication, unless used in conjunction with some external secure systems, such as SSL. In digest authentication, the user ID and a hash value of the password are transmitted to the server as part of an HTTP header. Therefore, the password does not appear in cleartext, which is the biggest weakness of basic authentication. When digest authentication is specified, the Web server responds to the client's request by requiring digest authentication. A one-way hash of the password (see Section 10.2.2.4 on page 356), as specifed by the Request for Comments (RFC) 2617,[3] is computed by the client, based on a random number, called nonce, uniquely generated by the server each time a 401 response is made. The hash value of the password is sent to the server, which computes the digest of the password for the user ID and compares the resulting hash value with the one submitted by the client. The requesting user is considered to be authenticated if the hash values are identical.
This mode of authentication assumes that the server has access to the user's password in cleartext�a necessary requirement in order for the server to compute the hash of the password. However, this is rarely the case in most enterprise environments, as the password in cleartext is not retrievable from a user repository containing the user ID and password information. Rather, the server typically delegates responsibility to the user repository to validate a user's password. Therefore, digest authentication is not widely adopted in enterprise environments and hence is not required to be supported by a J2EE container. J2EE servers that do support digest authentication can be configured to issue a digest authentication challenge by setting the value of the auth-method element in the login-config descriptor to DIGEST. Listing 3.5 is a deployment descriptor fragment illustrating how a J2EE server can be configured to require digest authentication. Listing 3.5. Login Configuration for Digest Authentication
The second authentication method is form based. With this method, the auth-method element in the login-config element must be set to FORM. The form-based authentication method assumes that the server is configured to send the client an HTML form to retrieve the user ID and password from the Web user, as opposed to sending a 401 HTTP unauthorized client error code as in the basic challenge type. The configuration information for a form-based authentication method is specified through the form-login-config element in the login-config element. This element contains two subelements: form-login-page and form-error-page.
Listing 3.6 is a sample HTML page for the login form. Listing 3.6. Login Page Contents
Listing 3.7 is a deployment descriptor fragment showing an example of login configuration that requires form-based authentication. Listing 3.7. Login Configuration for Form-Based Authentication
The third type of authentication method is certificate based (X.509 certificate). In order for the authentication method to be certificate based, the auth-method element in the login-config descriptor must be set to CLIENT-CERT. The certificate-based authentication method implies that the Web server is configured to perform mutual authentication over SSL. The client is required to present a certificate to establish the connection. When the CLIENT-CERT mode is specified, the client will be required to submit the request over an HTTPS connection. If the request is not already over HTTPS, the J2EE product will redirect the client over an HTTPS connection. Successful establishment of an SSL connection implies that the client has presented its own certificate and not anyone else's. The details of how the server ensures that the client certificate really belongs to the client are explained in Section 10.3.4 on page 372 and Section 13.1.2 on page 452. The certificate used by the client is then mapped to an identity in the user registry the J2EE product is configured to use. Listing 3.8 is a deployment descriptor fragment showing an example of login configuration that requires certificate-based authentication. Listing 3.8. Login Configuration for Certificate-Based Authentication
Note that the user registry is not specified in this XML deployment descriptor fragment because it is not part of the J2EE specification. 3.9.1.2 Secure-Channel ConstraintEstablishing an HTTPS session between the client and the Web server is often a necessary requirement to provide data confidentiality and integrity for the information flowing between the HTTP client and the server. In a J2EE environment, the security policy can require the use of a secure channel, specified through the user-data-contraint deployment descriptor element. When the requirement for a secure channel is specified, the request to the URI resource should be initiated over an HTTPS connection. If access is not already via a HTTPS session, the request is redirected over an HTTPS connection. Specifying INTEGRAL or CONFIDENTIAL as the value for the transport-guarantee element in the user-data-constraint descriptor will be treated as a requirement for the HTTP request to be over SSL. This requirement can be specified as part of the user-data-constraint element in a Web application's login configuration. In theory, INTEGRAL should enforce communitcation integrity, whereas CONFIDENTIAL should enforce communication confidentiality, and it could be possible to select different cipher suites to satisfy these requirements. However, a J2EE server typically does not differentiate INTEGRAL from CONFIDENTIAL but instead treats both of these values to indicate the need to require an SSL connection with a particular cipher suite, not based on whether INTEGRAL or CONFIDENTIAL was specified. Listing 3.9 is a deployment descriptor fragment showing an example of login configuration that contains the user-data-constraint element. More details are provided in Section 4.6.6 on page 132. Listing 3.9. Specifying the Requirement for a Secure Channel
3.9.2 Authorization PolicyThe role-permission interpretation of the J2EE security model treats a security role to be a set of permissions. The security role uses the role-name label defined in the method-permission element of an EJB module's deployment descriptor and in the security-constraint element of a Web module's deployment descriptor as the name of the set of permissions. The set of permissions defines a number of resources�the enterprise beans and the Web resources to which the method-permission and security-constraint elements refer, respectively�and a set of actions�the methods listed by the method-permission and the security-constraint descriptors. For example, in Listing 3.2 on page 74, the security role Teller is associated with the permissions to invoke the getBalance() and getDetails() methods on the AccountBean enterprise bean. Similarly, in Listing 3.3 on page 75, the security role Teller is associated with the permission to perform a GET invocation over HTTP to the /finance/account/ URI. If multiple method-permission and security-constraint descriptors refer to the same security role, they are all taken to contribute to the same role permission. In other words, the sets of permissions associated with that security role are merged to form a single set. This model has the advantage of dramatically reducing the number of objects in a security object space�a set of pairs (subject, <target, operation>), where the subject is an entity requesting to perform a security-sensitive operation on a given target. The Deployer and the System Administrator can define authorization policies, associated with EJB or URI targets and the operations of enterprise bean methods and HTTP methods, respectively, for the security roles in their applications. Then, they associate subjects to security roles; by extension, those subjects are granted the permissions to perform the operations permitted by the security roles. Based on the J2EE security model, a protected action can be performed by a subject who has been granted at least one of the security roles associated with the action. The security roles associated with a protected action are the required security roles�the permissions necessary to perform the action itself. The roles associated with a subject are the granted security roles�the permissions that have been given to that subject. This means that the subject will be allowed to perform an action if the subject's granted security roles contain at least one of the required security roles to perform that action. For example, if the action consisting of accessing the EJB method getDetails() on the AccountBean enterprise bean can be performed only by the security roles Teller and Supervisor and if subject Bob has been granted the security role of Teller, Bob will be allowed to perform that action, even if Bob has not been granted the security role of Supervisor. The table that represents the association of security roles to sets of permissions is called the method-permission table. A method-permission table (see Table 3.1) can be used to deduce the set of required security roles. The rows in the table represent security roles; the columns represent protected actions. It can be inferred from Table 3.1 that in order to access the getBalance() method on AccountBean, the required security roles are Teller and Supervisor. In order to access any URI that matches the pattern /public/*, a PublicRole is required.
| /finance/ | /public/* | AccountBean. | AccountBean | ||
|---|---|---|---|---|---|---|
Teller | Yes | No | No | Yes | Yes | |
Supervisor | Yes | Yes | No | Yes | Yes | |
PublicRole | No | No | Yes | No | No |
The table that represents the association of roles to subjects is called the authorization table, or protection matrix. In such a table, the security role is defined as the security object, and users and groups are defined as security subjects. An authorization table (see Table 3.2) can be used to deduce the set of granted security roles. The rows in the table refer to the users and user groups that are security subjects in the protection matrix; the columns represent the J2EE security roles that are security objects in the protection matrix.
Teller | Supervisor | PublicRole | |
|---|---|---|---|
TellerGroup | Yes | No | No |
ManagerGroup | No | Yes | No |
Everyone | No | No | Yes |
Bob | Yes | No | No |
The method-permission table and the protection matrix reflect the configuration specified in the deployment descriptors. For example, the first row in Table 3.1 reflects the deployment descriptor obtained from the deployment descriptor fragments of Listing 3.2 on page 74 and Listing 3.3 on page 75. It can be inferred from Table 3.2 that user Bob and group TellerGroup are granted the security role of Teller, everyone is granted the PublicRole, and only users in the ManagerGroup are granted the security role of Supervisor.
Combining Table 3.1 and Table 3.2, it follows that Bob can access the getBalance() and getDetails() methods on the AccountBean enterprise bean and can issue an HTTP GET request on the /finance/account/ URI. Bob cannot, however, issue an HTTP PUT request on the /finance/account/ URI. Note that Bob will be able to access any URI that matches /public/*, as everyone has been granted the role PublicRole, which is the role necessary to get access to /public/*.
In the J2EE security model, the Application Assembler defines the initial mapping of actions on the protected resources to the set of the required security roles (see Section 3.7.2 on page 67). This can be done using the application assembly tool. Subsequently, the Deployer will refine the policies specified by the Application Assembler when installing the application into a J2EE environment (see Section 3.7.3 on page 70). The Deployer also can use the application assembly tool to redefine the security policies, when necessary, and then install the application into the J2EE container. The method-permission table is formed as a result of the required security roles getting specified through the process of application assembly and refinement during deployment.
Authorization policies can be broadly categorized into application policies, which are specified in deployment descriptors and map J2EE resources to roles, and authorization bindings, which reflect role to user or group mapping. As discussed in Section 3.7.2 on page 67, a set of security roles is associated with actions on J2EE protected resources. These associations are defined in the J2EE deployment descriptors when an application is assembled and deployed. The security roles specified in this way are the required security roles�the sets of permissions that users must be granted in order to be able to perform actions on protected resources. Pragmatically, before a user is allowed to perform an action on a protected resource, either that same user or one of the groups that user is a member of should be granted at least one of the required security roles associated with that protected resource. The authorization table that relates the application-scoped required security roles to users and user groups is managed within the J2EE Product Provider using the J2EE Product Provider configuration tools.
3.9.3 Delegation Policy
Earlier in this chapter, we defined delegation as the process of forwarding a principal's credentials with the cascaded downstream requests. Enforcement of delegation policies affects the identity under which the intermediary will perform the downstream invocations on other components. By default, the intermediary will impersonate the requesting client when making the downstream calls. The downstream resources do not know about the real identity, prior to impersonation, of the intermediary. Alternatively, the intermediary may perform the downstream invocations using a different identity. In either case, the access decisions on the downstream objects are based on the identity at the outbound call from the intermediary. To summarize, in a J2EE environment, the identity under which the intermediary will perform a task can be either
The client's identity�
the identity under which the client is making the request to the intermediary
A specified identity�
an identity in terms of a role indicated via deployment descriptor configuration
The application deployment environment determines whether the client or a specified identity is appropriate.
The Application Assembler can use the security-identity element to define a delegation identity for an enterprise bean's method in the deployment descriptor. Consider an example in which a user, Bob, invokes methods on a SavingsAccountBean enterprise bean. SavingsAccountBean exposes three methods�getBalance(), setBalance(), and transferToOtherBank()�and its delegation policy is defined as in Table 3.3. Figure 3.5 shows a possible scenario based on the delegation policy specified in Table 3.3.
Figure 3.5. Delegation Policy Scenario
The method setBalance() will execute under the client's identity because the delegation mode is set to use-caller-identity. The method getBalance() will execute under the client's identity as well because no delegation mode is specified, and the default is use-caller-identity. Therefore, if Bob invokes the method getBalance() on AccountBean, the method will execute under Bob's identity, bob. Suppose that the getBalance() method invokes a lookup() method on SavingsAccountBean. This invocation will still be executed under Bob's identity and will succeed only if Bob has been granted the permission to invoke lookup() on SavingsAccountBean.
Method | Delegation Mode | Specified Role |
|---|---|---|
getBalance() | ||
setBalance() | use-caller-identity | |
transferToOtherBank() | run-as | Supervisor |
Any downstream call from transferToOtherBank() will perform method calls on a TransferBean enterprise bean. These invocations will need to execute under a principal that has been granted the Supervisor role. The Deployer or the System Adminstrator needs to map the Supervisor role to a principal that has been granted the Supervisor role. This can be done by specifying a valid user ID and password pair corresponding to a user who has been granted that role. For example, if user Alice has been granted the Supervisor role and if the user ID and password pair for Alice is associated with the Supervisor role, the calls to transferToOtherBank() will occur under Alice's identity.
3.9.4 Connection Policy
Information in any EIS must be protected from unauthorized access. An EIS system is likely to have its own authorization model. At a minimum, most of these systems have facilities to accept some form of authentication data representing an identity connecting to the EIS. The JCA is designed to extend the end-to-end security model for J2EE-based applications to include integration with EISs. A WAS and an EIS collaborate to ensure the proper authentication of a resource principal when establishing a connection to a target EIS. As discussed in Section 3.4 on page 61, the JCA allows for two ways to sign on to an EIS: container-managed sign-on and component-managed sign-on.
With container-managed sign-on, the connection to an EIS is obtained through declarative security. In order for a connection to be container managed, the deployment descriptor will indicate that the res-auth element associated with a resource definition is declared as Container. If the connection is obtained by passing the identity information programmatically, the value for res-auth should be set to Application. Details of component-managed sign-on are discussed in Section 3.10.3 on page 96.
A deployment descriptor fragment that declares that the authentication facilitated by the resource adapter should be set to be Container is shown in Listing 3.10.
Listing 3.10. An XML res-auth Element in a Deployment Descriptor
<resource-ref>
<description>Connection to myConnection</description>
<res-ref-name>eis/myConnection</res-ref-name>
<res-type>javax.resource.cci.ConnectionFactory</res-type>
<res-auth>Container</res-auth>
</resource-ref>
The container is responsible for obtaining appropriate user authentication information needed to access the EIS. The connection to the EIS is facilitated by the specified resource adapter. The JCA allows specifying the authentication mechanism. The authentication-mechanism-type element in the deployment descriptor is used to specify whether a resource adapter supports a specific authentication mechanism. This XML element is a subelement of the authentication-mechanism element. The JCA specification supports the following authentication mechanisms:
Basic authentication.
The authentication mechanism is based on user ID and password. In this case, the authentication-mechanism-type XML element in the deployment descriptor is set to BasicPassword.
Kerberos V5.
The authentication mechanism is based on Kerberos V5. In this case, the authentication-mechanism-type element in the deployment descriptor is set to Kerbv5.
Other authentication mechanisms are outside the scope of the JCA specification.
In a secure environment, it is likely that a J2EE application component, such as an enterprise bean, and the EIS system that is accessed through the component are secured under different security domains, where a security domain is a scope within which certain common security mechanisms and policies are established. In such cases, the identity under which the J2EE component is accessed should be mapped to an identity under which the EIS is to be accessed. Figure 3.6 depicts a possible scenario.
Figure 3.6. Credential Mapping when Accessing an EIS from a J2EE Container
In this scenario, an enterprise bean in a J2EE container is accessed by a user, Bob Smith. The enterprise bean is protected in a way that it allows only users from a specified LDAP directory to access it. Therefore, the identity under which Bob Smith will access the enterprise bean must be registered in that LDAP directory. Bob Smith uses the identity of bsmith when he accesses the enterprise bean.
In a simplistic case, where the run-as policy of the enterprise bean is set to be the caller identity, the connections to the EIS will be obtained on behalf of Bob Smith. If the connections are obtained through user ID and password, when the enterprise bean obtains a connection to a back-end system, such as a CICS system, the J2EE container will retrieve a user ID and password to act on behalf of user bsmith. The application invokes the getConnection() method on the javax.resource.cci.ConnectionFactory instance (see Listing 3.10 on page 89) with no security-related parameters, as shown in Listing 3.11, a fragment of Java code.
The application relies on the container to manage the sign-on to the EIS instance. This is possible in simple deployment scenarios in which the identity under which the EIS system is accessed is specified by the Deployer. This effectively means that all identities accessing the application are mapped to a single identity to access the EIS system: a many-to-one identity mapping.
Listing 3.11. Getting a Connection to an EIS with Container-Managed Sign-On
// Construct the InitialContext
Context initctx = new InitialContext();
// Perform a JNDI lookup to obtain a ConnectionFactory
javax.resource.cci.ConnectionFactory cxf =
(javax.resource.cci.ConnectionFactory) initctx.lookup
("java:comp/env/eis/MyEIS");
// Invoke the ConnectionFactory to obtain a connection.
// The security information is not passed to the
// getConnection() method
javax.resource.cci.Connection cx = cxf.getConnection();
In more sophisticated deployment scenarios, a many-to-one identity mapping may not be sufficient for security policy reasons. For example, it may be necessary for the EIS system to log all the identities that accessed it. For this logging facility to be useful, the identities accessing a J2EE application must not all be mapped to the same identity on the EIS system. A one-to-one or many-to-many identity mapping is recommended in this case. In particular, the container may use a credential mapping facility whereby bsmith is mapped to user ID bobsmith and password db2foobar, as shown in Figure 3.6.
If connections require Kerberos credentials or other generic credentials to be passed, the mapping facility is responsible for mapping one form of the credential to another that can be used by the target security domain. The manner in which these mappings happen and the level of sophistication in mapping available in J2EE application servers are server specific and not dictated by the J2EE specification.
In enterprise environments consisting of multiple departments, organizations, and even acquired companies, it is typical for systems to be interconnected and the applications shared. In such environments in which J2EE applications are deployed, it is a good architectural approach to design the application integration in a way that applications use JCA to obtain connections to other applications and to follow the declarative approach to define connection sign-on, as explained in this section. The use of JCA will make applications unaware of cross-security domains when accessing non-J2EE systems, and the use of declarative security will enhance application flexibility and portability. JCA with declarative security will also help manage the mapping of credentials and identities outside the application as enforced and facilitated by the enterprise-level mapping infrastructure.
< Day Day Up > |