Home > Articles > Programming > Java

This chapter is from the book

Security for Interoperability

Previous chapters have discussed that Java and .NET applications can interoperate synchronously or asynchronously in different architecture tiers. As security is end-to-end, security for interoperability should not be limited to a single application component (for example, .NET bridge) or a specific architecture tier (for example, Web tier). Further, the security requirements for interoperability in each architecture tier are different. This section discusses the security requirements and what enabling technologies and security standards are available to address these requirements. The details of security standards for interoperability are discussed in the next section. Adopting interoperability technologies that support security standards allows wider choice of vendor products and easier implementation.

Figure 13-3 depicts the areas of security for interoperability that have support for security standards such as WS-I Basic Security Profile and WS-Security. A Java client should be able to perform a single sign-on with the .NET application and similarly for a .NET client with a Java application. To ensure client-to-server communication is secure, developers can use HTTPS or SSL/TLS to encrypt the communication channel.

Figure 13.3

Figure 13-3 Security for interoperability

In both the Web and the Business tiers, the client should be able to initiate service requests or exchange business data synchronously or asynchronously using Web services (with WS-I BSP and WS-Security). This should allow a servlet, JSP, or JSF component under the Web tier to interoperate with a .NET service component under the Business tier—or an ASP.NET page under the Web tier to interoperate with an EJB object under the Business tier.

In the Resource tier, a Java servlet or EJB component can also request access to resources such as business data and database objects implemented by means of the Data Access Layer using a policy language such as WS-Policy, XACML, and Web Services Policy Language (refer to next section for more details). Similarly, a .NET-serviced component can also share the same policy language (provided that they are available in both .NET and Java language) when requesting access to resources via Data Access Objects or Entity Beans.

There are always business scenarios in the existing or legacy environment that Figure 13-3 does not cover. As most of these scenarios use nonstandard interoperability technologies that are usually proprietary or highly customized on a case-by-case basis, they require additional cost and efforts to analyze the potential security risks and to mitigate the vulnerabilities. For example, if a bridge technology is used for Java EE .NET interoperability, developers and security architects need to analyze the risks of the bridge technology and the customized application codes that connect to the bridge. The bridge would become an easier target for hacking or the single point of failure attacks. Even though the security for the bridge is strong, there may be considerable unknown risks for the customized application codes related to it.

The following sections elaborate on the security requirements of the Java EE .NET interoperability and discuss the technologies available to mitigate the security risks.

Secure Transport

The client-to-server session is often a target of security spoofing. A basic security requirement for interoperability when exchanging user credentials or sensitive business data is secure data transport. Java and .NET applications can use HTTPS or SSL/TLS in the data transport layer to secure the client-to-server session. Secure data transport can ensure confidentiality and reduce the risk of principal spoofing.

Security Interoperability by Tiers

Interoperability at the Web Tier

A Java client can authenticate with an Active Directory or a Directory Server using a JAAS login module. Similarly, a .NET client can authenticate with a Directory Server. Digital certificates can be used as a common user credential; however, Java and .NET clients need to create shared session state in order to interoperate in a heterogeneous environment. The capability to authenticate with both Java and .NET application servers and to create shared common session data are key security requirements for interoperability. These security requirements allow the Principal to share session information between the Java and .NET environments and not necessitate relogin.

A Java client can authenticate with a .NET application using the shared authentication approach. Similarly, a .NET client can also authenticate with a Java application using the same shared authentication approach. Shared authentication here refers to the use of form-based authentication and customization of shared session data for both Java and .NET applications. Form-based authentication allows page-level authentication to a Web application. Shared session data can be stored in a customized shared session state database or a Directory Server using existing session APIs in both Java and .NET platforms—for example, Java has many APIs under the javax.servlet.http.HttpSession class, and .NET has SharedSession object.

Nevertheless, customized processing logic for shared authentication and shared session data are often proprietary and are specific to certain implementation. The use of Web SSO MEX (Single Sign-on metadata Exchange) protocols is a proposed standard for Java EE .NET interoperability to achieve single sign-on and should be recommended. Please refer to the following section for more details.

Shared authentication, shared session data, and single sign-on using Web SSO MEX protocol are mechanisms to address broken authentication and session management. They also rely on strong authentication mechanisms, for example, use of digital certificates and strong user passwords, and reliable authentication infrastructure such as Directory Server. For Web services such as asynchronous SOAP messages, it is critical to use the WS-I Basic Security Profile (BSP) and WS-Security standards. WS-I BSP ensures that both Java and .NET applications are using a common semantic for SOAP messages. WS-Security supports service requests or replies that are digitally signed and/or encrypted to ensure confidentiality. It addresses the risk of message alteration, attachment alteration, falsified messages, repudiation, forged claims, and message replay.

Interoperability at the Business Tier

Security interoperability requirements for the Business tier are similar to those for the Web tier. The key difference is that the Business tier interaction is often server-to-server, not client-to-server. Interaction between .NET- serviced components and EJBs or service requests from the Web tier are often point-to-point, and these components do not use SSL/TLS, which is used for client-to-server communication. Customized and point-to-point security processing logic (for example, encrypted transactions) that secures the business transactions in the Business tier is usually proprietary and is unlikely to be reusable in another environment. For interoperability using Web services, WS-I BSP and WS-Security provide an open standard to secure business transactions. For interoperability using a bridge technology, developers need to rely on customized encryption or proprietary security mechanism.

Interoperability at the Resource Tier

Both Java and .NET platforms support a variety of access control mechanisms to determine which resources are accessible to the service requesters. They may either embed the access control processing logic into the programming codes or use a policy framework. Using a policy framework, developers can decouple the custom access control processing logic from the application codes. Because the access control processing logic is separate from the application codes, it will be more flexible, allowing management of changes without the need to recompile or retest the entire application for every security policy change.

Without a common policy framework, an interoperability solution needs to rely on two different access control systems. If the two policy frameworks are "out of sync," the service requester may be denied access. It is also time-consuming to troubleshoot which side of the policy framework is problematic.

The use of common and standard security policies, such as WS-Policy and XACML, across Java and .NET platforms addresses the risk of broken access control. For example, Microsoft’s Web Services Enhancement provides support for WS-Policy, and Sun’s XACML Kit is available on both Java and .NET platforms. Please refer to the next section for details on these policy frameworks.

Support of Audit Control and Compliance

In recent years, support of audit control and compliance (for example, Sarbanes-Oxley, Gramm-Leach-Bliley Act of 1994, HIPPA or Health Insurance Privacy and Portability Act of 1996) has become a key security interoperability requirement. These compliance requirements are focused in building the capability for tracking unusual or suspicious user activities, ranging from unauthorized access to suspicious high volume business transactions. They also require a timely report of the unusual or suspicious security events, and tracing the source of the service requesters. Thus, it is extremely important that the Java and .NET interoperability design should be able to have risk mitigation mechanisms for security attacks, and to build up capability for "track and trace" of any unusual security events and service requests.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020