Related Topics: Java EE Journal

J2EE Journal: Article

The New Security Architecture of BEA WebLogic Server 7.0

The New Security Architecture of BEA WebLogic Server 7.0

Installing and maintaining security is a huge challenge for an IT organization. To serve a worldwide network of Web-based users, the IT organization must address the fundamental issues of maintaining the confidentiality, integrity, and availability of the system and its data. Security across the infrastructure is a complex business that requires vigilance and established and well-communicated security policies and procedures.

This article looks at securing the Java-based application and the WebLogic Server on which it is deployed. WebLogic Server 7.0 incorporates a completely redesigned security architecture that provides a unique and secure foundation for applications. WebLogic Server 7.0 security services can be used standalone to secure WebLogic Server applications, or as part of an enterprise-wide security management system that represents best-in-breed third-party security management solutions.

Security Issues Facing Customers Today
So, what are the problems with security? Well, there are quite a few, but the major ones that we've heard from customers are:

  • Application security today is in the hands of application developers. In order to implement really strong security or any kind of business security rules, the security-related code is included in the application. Since developers are typically not security experts, this makes it error prone and extremely costly to develop and maintain.
  • Hardcoded security policies are inflexible and policy changes require changes to application code, which is slow and expensive.
  • The need to integrate new applications with existing security products usually requires a very costly "custom code" to plug into third party products.

    Today, customers have to build aspects of application security directly into their applications. By building proprietary connectors, they can utilize the third-party point security solutions directly, which of course locks them into a single vendor and proprietary technology. And, if any intelligent business security rules need to be implemented - customers build their own security policy systems. This distracts them from implementing their core business functionality and increases time-to-market immensely.

    Why Is J2EE Not Good Enough?
    J2EE security attempted to provide a simple infrastructure to solve security issues. However, it turned out that in the real world J2EE security standards aren't strong enough or flexible enough, and in general don't have many of the features required by a modern agile enterprise application. These are some of the problems with J2EE security:
    1.   Requires developers to hard code security into the business logic and configuration files.
    2.   Administrators cannot change security settings - they need to know too many things to do it.
    3.   Developers and administrators cannot implement business rules for security policy - there is no concept of business security rules in J2EE.
    4.   Only controls certain J2EE components (EJBs, servlets, JSPs), not the entire application (what about JCA, JMS, databases, and all those non-J2EE components like Web services?).
    5.   Not integrated with the leading security ISV solutions that might be an existing corporate standard - many of these products are not even based on J2EE.
    6.   Has no provisions for Single Sign-On (SSO).

    The Solution:
    A Security Framework

    The WebLogic Security Framework, new in WebLogic Server 7.0, provides end-to-end application security, covering J2EE and non-J2EE components of your application hosted on WebLogic Server. With WebLogic security:
    1.   Security policies are created and managed by Security Administrators.
    2.   Security policies are flexible, dynamic, powerful rules that can be changed without recoding and redeployment.
    3.   Integration with existing security solutions is greatly simplified.

    Unlike J2EE, the WebLogic Security Framework separates application business logic from the security code. Security services, including security business rules, are provided by the infrastructure and don't have to be coded in the application. It's easy for nondevelopers to administer and doesn't require any programming or XML knowledge. A GUI for security administration is provided out-of-the-box.

    A built-in dynamic security rules engine makes it easy to implement dynamic business rules for security policies, and does not require any downtime to update these rules. It allows mapping company business rules to security policies in distributed deployments, providing easy customization of application security to business requirements.

    With an open Security Service Provider Interface (SSPI) the framework allows leading security solutions on the market to plug in and provide their security services to WebLogic applications, and also enables adding custom extensions. In addition, WebLogic Server 7.0 provides prebuilt implementations (security service providers) for most of these plug-in points.

    Single Sign-On is automatically available to WebLogic Server applications without any additional programming.

    WebLogic Server provides a complete range of security coverage for all J2EE and non-J2EE components deployed in WebLogic Server.

    Having said all this, it's important to remember that as a certified J2EE 1.3-compliant application server, WebLogic Server supports all the security features required by J2EE, such as JAAS. Also, it supports the WebLogic Server 6.x security model by providing a "compatibility mode" which should make it easy and painless to transition from the older 6.x security model to a new security framework.

    With an open architecture, standards support, and unified administration, WebLogic Server 7.0 security gives the IT department the tools it needs to address real-world issues in security.

    Putting It All Together: the New Security Architecture
    Figure 1 shows the WebLogic Server 7.0 service-based Security Framework, which provides interfaces to other BEA products, J2EE containers, and customer applications, and delegates requests to the appropriate security plug-in. Security plug-ins supplied by BEA with WebLogic Server perform the following functions out-of-the-box:

  • Authentication: Authenticates, verifies, and maps security tokens to an internal format for security support. Supports delegated username/password and certificate authentication with WebLogic Server, and HTTP certificate authentication via the standard service provided in a Web server.
  • Authorization: Enforces authorization policies for resources, taking business policies into consideration. Supports role-based authorization, in which access is based on job function and business rules.
  • Auditing: Audits all security actions in support of non-repudiation. Provides a customizable set of data for auditing security events such as failed login attempts, authentication requests, rejected digital certificates, and invalid roles.
  • Public key infrastructure: Supports standard public key encryption for data or digital signatures, or when electronic authentication of a client's identity is required.
  • Credential mapping: Maps a user's authentication credentials to those required for legacy applications, so that the legacy application gets the necessary credential information.
  • Role mapping: Maps roles to users or groups, based on policy. Determines the appropriate set of roles granted to a WebLogic Server user or group for a WebLogic resource.

    The Security SPI: the Interface for Flexibility
    The security plug-in scheme in WebLogic Server 7.0 is based on a set of Security Service Provider Interfaces (SPIs) for the plug-in points. The Security SPIs can be used by customers or third-party vendors to develop security plug-ins for the WebLogic Server environment. Security SPIs are available for authentication, authorization, auditing, credential mapping, role mapping, and the public key infrastructure (supporting the Java standard Key Store for encrypted storage of public and private encryption keys).

    The Security SPI scheme means that customers have four choices for securing WebLogic Server installations:

  • BEA-supplied security plug-ins
  • Third-party security plug-ins based on the BEA Security SPI interface
  • BEA Security SPIs to create customized security plug-ins for WebLogic Server systems
  • Existing third-party security technologies that have been adapted so that they are BEA-compliant (some are available today or are coming in the near future)

    An Open Architecture:
    Multi-Vendor and Multi-Protocol Support

    The open, interface-based security architecture in WebLogic Server allows use of existing security products while taking advantage of new security technologies available in the marketplace. With this architecture, a security installation can support security vendors' full value propositions, not just a subset. A user's choice of security products can be "mixed and matched" to create complete custom security solutions. In fact, WebLogic Server installation can run more than one security plug-in for a given function, and users can set constraints that govern which product or protocol will be used in a given situation.

    As users integrate new solutions or modify existing ones, administrators can set security policy for each security plug-in, using a built-in menu-driven policy tool. Security policy governs authorization: the rules and constraints for accessing resources or assuming roles. More than one security plug-in can run concurrently, as part of a migration or transition scheme, and set security policy accordingly. The BEA-supplied Adjudicator function resolves any conflicts in interpretation when making authorization decisions.

    The WebLogic Server 7.0 design for security services supports any choice of vendors and protocols because it separates the details of the security system from application code, simplifying application maintenance and management. Changing security system components or policies need not entail modifying applications. This unified architecture makes it easy to integrate best-of-breed security solutions, and to replace components of a security system with the latest technologies from third-party vendors, or from a development staff. The ability to swap in new security plug-ins and technologies as needed reduces the total cost of ownership and maximizes the return on investment in security technologies.

    Advantages for Developers, Administrators, and Vendors
    Figure 2 illustrates how different users would interact with the software architecture of the WebLogic Server security services. The new security architecture has benefits for three categories of users: application developers administrators, and third-party security service vendors.

    Benefits for Application Developers
    Since most of the security functionality for Web applications can be implemented by a system administrator, application developers need not pay attention to the details of securing the application unless there are special considerations that must be addressed in the code. In cases where programming custom security into an application is required, WebLogic Server application developers can take advantage of BEA-supplied Application Programming Interfaces (APIs) for obtaining information about subjects and principals (identifying information for users) that are used by WebLogic Server. The APIs are found in the package.

    With WebLogic Server's support for the Java standards, developers can also use the APIs in the Java platform security packages such as JAAS and JSSE, as well as the security-specific methods defined by J2EE.

    Benefits for Administrators
    Administrators who install, configure, deploy, and maintain WebLogic Server can use their choice of BEA-supplied security plug-ins, customized security plug-ins, or third-party security products, and manage them all with the Administration Console.

    Out-of-the-box, a complete security solution can be implemented using the BEA-supplied security plug-ins. Administrators can use the menu-driven rule-based policy engine to create an authorization scheme that implements your company's business rules.

    Setting Policies: No Programming Required
    The built-in Policy engine provides a GUI interface that lets Administrators set policies in the Administration Console, without writing application code. By right clicking on the system resource displayed in the Administration Console, users can select among the constraints displayed on the drop-down menus. Figure 3 illustrates this simple menu-based approach to adding or changing security in applications.

    Benefits for Third-Party Security Vendors
    Most leading security service providers have announced plans to support WebLogic Server 7.0. These providers are integrating their products with the WebLogic Server environment using the Security SPIs. As the underlying integration mechanism for BEA's security plug-ins, the Security SPIs permit development of customized security plug-ins for the WebLogic Server environment. Security SPIs are available for authentication, authorization, auditing, public key infrastructure, credential mapping, and role mapping. This allows third-party vendors to provide tightly integrated solutions that are easy to implement.

    Security via Users, Roles and Policies
    The key to WebLogic Server 7.0's security architecture is the organization of application users into users and groups that take on roles according to defined security policies. Users can be organized into groups. Groups can be used to represent organizational boundaries as well as to simplify administration. Each application user and group is mapped to a role dynamically during application execution, when authorization is needed.

    Roles and policies determine access to system resources, and permitted behaviors. User roles are registered by an administrator using the built-in menu-driven security policy tool embedded in the BEA-supplied Authorization plug-in. The security policy tool's interface reflects business concepts, not programming concepts, and allows an administrator to create simple prose-based rules for dynamically assigning roles and calculating access privileges. Application developers are freed from having to write application code to implement complex business policies, because the policy tool separates the tasks of business policy creation and application creation.

    The roles that a user can be assigned to are determined by policies defined by the administrator, on behalf of the company. Since policies reflect business security rules, a company's management sets security policies rather than the software development staff. Security policies can easily be changed with changes in business conditions.

    The role-and-policy-based security scheme replaces the previous scheme of users, groups, and access control lists (ACLs), and offers clear advantages for ease of administration and ease of adaptability as security requirements change. Using roles and policies for authorization permits dynamic computation of access status for each resource, for each user or group.

    WebLogic Server 7.0's dynamic, role-based authorization scheme can be applied to all WebLogic Server resources. The administrator and applications developer are no longer constrained by the limitations of the declarative security model in J2EE, which embeds security constraints in the code and makes it difficult to modify a security scheme when business requirements change.

    *  *  *

    Next month, I'll look at more of the details of the security functionality provided by WebLogic Server 7.0.

  • More Stories By Vadim Rosenberg

    Vadim Rosenberg is the product marketing manager for BEA WebLogic Server. Before joining BEA two years ago, Vadim had spent 13 years in business software engineering, most recently at Compaq Computers (Tandem Division) developing a fault-tolerant and highly scalable J2EE framework.

    More Stories By Paul Patrick

    As chief security architect for BEA Systems, Paul Patrick is responsible for the overall security product strategy at BEA. He plays a key role in driving the design and implementation of security functionality across all of BEA’s products, and is the architect for BEA’s new enterprise security infrastructure product, WebLogic Enterprise Security. Prior to becoming chief security architect, Paul was the lead architect of BEA’s ObjectBroker CORBA ORB and co-architect of WebLogic Enterprise (now Tuxedo). He is also the author of several patent applications as well as industry publications and a book on CORBA.

    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.