Welcome!

Get the job done right the first time

Girish Gupte

Subscribe to Girish Gupte: eMailAlertsEmail Alerts
Get Girish Gupte via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

A Safe Architecture Framework

Leverage the security features of BEA WebLogic 8.1

EMALL is a procurement and collaborative commerce portal for the U.S. Department of Defense and based on J2EE and WebLogic Platform 8.1. One core component of EMALL is a rule engine based on WebLogic Platform 8.1.

EMALL integrates with Web applications, based on .NET and J2EE technology, through which DOD personnel submit and track orders. The rule engine validates these orders and submits requisitions to various defense suppliers. All of these systems interoperate, using ebXML 2.0, under stringent security requirements. In our previous article (WLDJ, Vol. 3, issue 1), we discussed the overall EMALL architecture. In this article, we will describe how we leveraged security aspects of the BEA WebLogic Platform to implement security solutions.

Security Requirements for EMALL
We will review and discuss some critical security requirements and analyze the threats and risks that this system must mitigate. EMALL handles sensitive information. Only authorized personnel with proper security privileges can perform tasks such as browsing the catalogs of various suppliers, reading the technical specifications of various products, submitting orders, and tracking order status. Accountability is also a critical requirement for this system.

Let's look at some of the important security threats:

  1. Man-in-middle attack: The EMALL system spans a large geographic area, and several networks, including some public segments.
  2. Message tampering: Attacker can try to modify the content of a message.
  3. Impersonation attack: The EMALL system includes several business and government entities. An attacker can try to impersonate a legitimate entity.
  4. Trojan horse: Several DOD personnel have access to EMALL. There is a threat from one or more individuals trying to compromise the system.
  5. Security breach at a subsystem: EMALL includes several subsystems, some located at a DOD supplier's networks. There could be a security breach at one such subsystem that can affect the entire EMALL.
Design Goals
We identified the following design goals to mitigate these risk factors:

Data Encryption
All traffic between various entities must be encrypted using strong encryption to prevent a man-in-middle attack.

Two-Way Authentication
Each entity participating in EMALL must identify itself using a digital certificate. Each data-exchange must enforce two-way-certificate verification to prevent an impersonation attack.

Control the Role of Each Subsystem within EMALL
Each subsystem entity provides specific services to other entities, and can invoke specific services from other entities. This would minimize the risk in case one of the subsystems is compromised

Access Control
Each subsystem would implement role-based security for their internal users. These mechanisms would be different for each subsystem. The rule engine will receive the user ID information within each message that it receives from the external subsystem when it receives requests. It will in turn propagate proper credentials to the subsystems when it invokes services.

Digital Signatures
Each message will be digitally signed to prevent unauthorized modification.

Audit Trails
Each message will be tracked using audit trails to identify a security breach and improve accountability. These trails would include the following information:

  • Content of the message
  • Digital signature of the message
  • Timestamp
  • User ID that initiated the message
Recipient must acknowledge each message.

BEA WebLogic Platform Components
Figure 1 represents various parts of the WebLogic Platform related to security infrastructure.

HTTPS and SSL Features
Some important aspects of SSL support provided by BEA WebLogic Server are relevant to EMALL.

Strong Encryption
BEA WebLogic Server supports 1024-bit certificates and 128-bit bulk data encryption.

Support for Asymmetric Key Cryptography:
WebLogic Server supports the RSA algorithm, including support for digital signatures.

Two-Way Certificate Verification
With this feature enabled, both the client and BEA WebLogic Server must present SSL certificates before a connection is established. WebLogic Server checks the following before establishing a connection:

  • The certificate is issued by a trusted certifying authority
  • The IP address/Host-Name in the certificate matches the client's IP address
WebLogic Security Provider Framework
BEA WebLogic Server supports J2EE declarative security including features such as user IDs, roles, access control lists, auditing, security events, etc. To implementing these features, WebLogic Server includes a security framework that can be extended using security provider modules. WebLogic Server comes with out-of-box implementations of these modules. You can plug your own custom implementations into the framework. Some of the modules relevant to EMALL include:
  1. Authentication providers: Authenticate users by verifying credentials supplied by the user. This could be a user ID/password, or could be certificate-based.
  2. WLSUser: Interface for the "Principal" object that holds security information representing a user.
  3. Identity assertion providers: Can use security tokens such as CSIv2, SAML, Kerberos, and Microsoft Passport.
  4. Principal validation providers: Handle signing, encrypting, and verification of security information across multiple WebLogic domains. It prevents malicious tampering of security information during RMI calls between WebLogic Servers.
  5. Authorization providers: Enforce security policies based on roles, user IDs, groups, etc., for all resources within BEA WebLogic Server.
  6. Role-mapping providers: Allow dynamic role association.
  7. Auditing providers: Tracks security events such as access to specific resources. It can record information such as user IDs, timestamps, credentials provided, and resources accessed. This information can be put into a database or a file. It can also trigger specific actions such as paging security personnel in response to security events.
Our planned architecture includes custom security provider modules to implement the following features of EMALL.
  1. Create a custom implementation class for WLSUser to propagate additional information such as a user's rank, security-clearance level, digital signatures, department etc.
  2. Develop a custom authentication provider that will interact with a central security database and authenticate the user. It will then extract all the necessary information and instantiate the custom WLSUser class.
  3. Develop a custom identity-assertion provider to implement single sign-on.
  4. Develop a custom authorization provider and custom role-mapping provider to enforce access control for secure information. This implementation will use the information (such as rank, clearance level, etc.) stored in a custom WLSUser implementation.
  5. Implement a custom audit provider to record activities. The information in the custom WLSUser object will be tracked in the audit trails.
This framework will be used by the rule engine and all other J2EE applications deployed on the BEA WebLogic Platform.

Until now we've discussed security features from the core BEA WebLogic Server. Now let's discuss the B2B security features provided by WebLogic Integration.

Using J2EE Declarative Security Constraints
The "rule engine" application includes several resources, such as URLs in Web applications and EJB methods that need to be protected by the Security Framework. We will use the J2EE security constraints defined in web.xml and ejb-jar.xml files for this purpose.

Trading Partner Configuration
BEA WebLogic Integration allows us to manage the relationships with other business entities by configuring trading partners. Some of the important features used in the EMALL security architecture include:

  1. Associating a digital certificate with a trading partner. These certificates will be used for encryption and signing of ebXML messages.
  2. Defining services offered by local and remote trading partners.
  3. Defining the protocol bindings for each service profile. This includes business protocol ebXML 1.0, ebXML 2.0, or RossettaNet and Transport Protocol (HTTP 1.0, HTTP 1.1 or HTTPS 1.1).
  4. Specifying roles for each "conversation" or Service invocation.
  5. Easy-to-use, centralized admin console interface for managing the trading partner configuration.
Using these features, we can manage the trading-partner configurations with all vendors participating in EMALL from the "Rule-Engine" application.

Implementation Notes
Several important points regarding implementation of the rule engine should be considered.

The ebXML participant process (acceptCart.jpd) receives the "Shopping Cart" document, which includes the user-metadata along with the other parameters. The code in this JPD file will extract this information from the XML payload and invoke a specific stateless EJB.

The BEA WebLogic Server Security framework will invoke the custom authentication provider, which instantiates a custom object implementing the weblogic.security.spi.WLSUser interface. The actual implementation class for this object also has additional fields to hold custom security data such as rank, digital signatures, etc.

In the stateless EJB method, we obtain the security context and the JAAS principal. This object is actually the custom implementation WLSUser created by our authentication provider. This object is cast to its original type, and then the fields containing additional custom data are populated.

When the JPD code invokes other functionality in the rule engine, these data fields are checked by the role-mapping provider, authorization provider, and so on.

When each protected resource is accessed, the custom audit provider is invoked by the WebLogic Security Framework. This audit provider extracts these data fields and logs them in the audit repository.

Nonrepudiation
The following architecture features support nonrepudiation in EMALL:

  1. Extensive audit trails: The custom audit provider records critical information including user-metadata, digital signatures, timestamps, etc., in the audit trails.
  2. ebXML supports digital signatures: Only the entity that owns the private-key for the digital certificate can sign the messages. This signature is irrefutable proof that the message was sent by the proper entity. In addition, once the message is received, ebXML allows for acknowledgement of the message, which is a proof that the recipient entity received the message. Together, these two (message signature and acknowledgment) are proof that the transaction is binding on both parties.
Conclusion
The EMALL system has stringent security requirements. Using the security features provided by BEA WebLogic Platform 8.1, we were able to develop an architecture framework that meets these goals. The WebLogic Security Provider Framework, support for SSL, and use of ebXML are the most important factors in our security architecture.

Acknowledgments
The authors would like to gratefully acknowledge the support of Dr. Bill Freeman, director of research and development for the Integrated Solutions Group of the South Carolina research Authority. Dr Freeman is also the project manager for SCRA's work on the DOD EMALL. BEA and ICF provide engineering services to SCRA. We would also like to thank Ricardo Valenzuela, Madhavan Rangarao, Dmitry Dimov, and Komal Mangtani from the BEA engineering team, who provided technical support to help us achieve our goals.

More Stories By Ashley Byrd

Ashley Byrd is a senior software engineer with the ICF Consulting software team. He has 15 yeasr of experience in application, the last 7 in full life-cycle, object-oriented Internet systems primarily for the financial services industry .

More Stories By Girish Gupte

SOA evangelist and system integrator with expertise in wide range of technologies. Track record in building complex, mission-critical applications with stringent security requirements. Worked in various industries such as DOD/Federal and financials.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.