Related Topics: Java EE Journal

J2EE Journal: Article

Authentication and Authorization with WebLogic Server Security Framework 7.0

Authentication and Authorization with WebLogic Server Security Framework 7.0

In the last issue of WebLogic Developer's Journal (Vol. 1, issue 12) we looked at some of the major features and functional areas of the new Security Framework in WebLogic Server 7.0.

Now let's take a closer look at how WebLogic Server 7.0 implements the primary task areas of a security system, which are authentication (determining a user's identity as a valid user), authorization (determining a user's role or roles and computing the appropriate access privileges based on the policies in place), and other essential areas of the WebLogic Security Framework.

Authentication is the process of ascertaining that an identity can be proven to be who it claims to be. In many security systems, the proof of identity is accomplished through the use of usernames and passwords. WebLogic Server 7.0 builds upon the authentication classes of the Java Authentication and Authorization Service (JAAS), which is a standard extension to the security in the Java Software Development Kit, version 1.3. The JAAS standard provides the support needed to submit a username and credential, typically a password, when authenticating a user to WebLogic Server. WebLogic Server goes beyond this by providing a link to legacy systems so a particular system's authentication credentials can be transparently used by WebLogic Server.

In addition, the new architecture supports the concept of perimeter-based authentication, where the actual authentication process occurs at an application perimeter such as a Web server, firewall, or VPN, and outside of WebLogic Server. The architecture provides support for multiple "security token types" (e.g., Microsoft Passport, SAML Assertions, or tokens from third-party commercial authentication products). WebLogic Server 's support for perimeter-based authentication supports the ability to propagate security tokes over multiple protocols, such as HTTP, and IIOP-CSIv2.

By default, WebLogic Server 7.0 supports a number of different forms of authentication:

  • Certificate based authentication directly with WebLogic Server using the SSL/TLS protocol
  • HTTP certificate-based, proxied through an external Web server
  • Username/password authentication

    WebLogic Server's security architecture is flexible enough to benefit developers who have special authentication situations. It provides integration with a number of different authentication technologies, including NT domains, Active Directory and other commercial LDAP directory servers, and Unix security services. For example, an organization might prefer to use the Unix security system for user authentication. In this scenario, WebLogic Server can be configured to defer authentication of users to Unix.

    Levels of Authentication
    Since authentication requirements vary greatly, the server is easily configurable to allow different levels of authentication depending upon the needs of the deployment. When a client, administrator, or peer wants to access a resource hosted on WebLogic Server, it may be necessary to authenticate the user's identities. WebLogic Server provides two default mechanisms for authenticating users: passwords and digital certificates.

    The most common form of authentication is password-based authentication, which allows users to enter a username and password as a means of authentication when requesting access to a given resource on the server. Password-based authentication is defined as Basic authentication by the HTTP protocol and the basis of form-based authentication. This form of authentication is very easy to implement and manage, but provides a weak form of authentication due to the lack of enforcement of good password practices..

    For stronger authentication, WebLogic Server supports the use of digital certificates. These certificates are issued from a trusted third-party called a Certificate Authority (CA). A CA issues certificates that can be used to prove the identity of servers or users. WebLogic Server does not restrict the number of CAs or the number of levels in a certificate chain. This provides more flexibility for businesses that choose to be their own CA.

    Authentication via digital certificates is the key to authentication using the Secure Sockets Layer (SSL) and Transport Level Security (TLS) protocols supported by WebLogic Server 7.0. WebLogic Server is capable of utilizing digital certificates that are compatible with the X.509v3 international digital certificate standard. This compatibility allows use of certificates from any CA that supports this standard. Both the SSL and the TLS security protocols support the concept of mutual authentication.

    In order for mutual authentication to be used as the means to authenticate the client, both client and server must present a digital certificate that indicates their identities before the connection is enabled between the two. When certificate-based authentication is used, the identity from the client's digital certificate can be validated through a customization point called a certificate authenticator that is registered with an Identity Asserter. The Identity Asserter creates a JAAS CallbackHandler object that is populated with the necessary information to map the identity asserted by the digital certificate to a WebLogic Server local user identity. The CallbackHandler is then passed to a JAAS LoginModule where the asserted identity in the CallbackHandler is verified to be one of a local registered user. If the verification is successful, the identity is then inserted as a Principal object into a JAAS Subject.

    WebLogic Server 7.0 provides full-strength, 128-bit encryption for customers in the United States and Canada, and international customers that are permitted to use full-strength encryption by U.S. trade laws. A 56-bit encryption scheme is compatible with "low-strength" encryption, allowing universal compatibility.

    Authorization determines what a user is allowed to access. J2EE defines the use of a role-based approach for container-based resources where a user must hold one or more roles in order to access the resource. WebLogic Server takes the role-based security model defined by J2EE and couples it with the ability to use policy to define the mapping of principals to roles and rules that specify the criteria that must be met to access a resource as a means to create a powerful and consistent authorization model.

    The role mapping and authorization policies of WebLogic Server determine the level of access a particular user has to all resources hosted on WebLogic Server, for example:

    • Enterprise JavaBeans
    • Web applications (servlets, JSP)
    • Miscellaneous J2EE resources (JCA adapters, JMS destinations, JNDI, JDBC)
    • Non-J2EE resources like Web services
    It's important to remember that the authorization model currently defined by the J2EE standard is not uniform across all of the resources. The declarative security described in deployment descriptors only covers limited J2EE resources like EJBs, servlets, and JSPs. Many J2EE vendors provide implementations of the J2EE authorization scheme that are static in that they have to be set through J2EE deployment descriptors before the application is deployed, and cannot be changed afterwards without modifying the deployment descriptor and potentially having to redeploy the application. Previous versions of WebLogic Server supported this model as well. In addition, there are currently no provisions in the J2EE authorization model to implement any kind of business access rules other than those purely based on the user role outside of the application itself.

    The separation of security enforcement in the application from the business logic simplifies security management and makes the application less fragile to changes in authorization and business policy. The authorization capabilities provided by the new security architecture also allow business parameters to optionally be taken into account to authorize a specific user's access to a specific resource under specific conditions. This allows the role-mapping and authorization policies to support more "real-life" conditions required for doing business.

    Role definitions are specific to a unified security realm that represents the broadest policy scope to which security policies apply (e.g., the entire company, the company's Western Division, the company's Pacific Rim branch). J2EE defines that roles can be defined as resource scoped - associated with given resources. WebLogic Server 7.0 extends this model with support for globally scoped roles that are associated with all resources. Roles can be assigned statically for specified users or groups at administration time, or dynamically, based on the context of the request at run-time.

    Role assignments are dynamically computed according to security policies, set by the administrator using the WebLogic Server Policy tool as the user seeks to access various resources. This new authorization scheme replaces the use of Access Control Lists (ACLs) for protection of non-container-based resources that was used in previous releases of WebLogic Server.

    WebLogic Server allows the concept of roles to be implemented as an identity, or as a named collection of permissions, thus creating a 'capabilities-based' authorization system. Because the implementation of roles can be different depending upon the implementation, it is necessary for there to be a tight coupling between role and authorization decisions.

    While J2EE-required security support is fully available with WebLogic Server, the power of the new Security Framework is in dynamic authorization and role mapping rules that are based on context, such as request parameters. The authorization and role-mapping policies can be defined by a security administrator through the use of the WebLogic Server administrative console and without having to edit XML deployment descriptors or involving a developer in order to change application business logic, and with no application redeployment required. Because it is often necessary for security policies to be changed dynamically as new users are added or situations change, WebLogic Server can dynamically update users and roles by leveraging an external, centralized security database or service, such as LDAP, or by using the embedded directory server.

    In order to provide a consistent approach to authorization and role mapping across all resources hosted on WebLogic Server, the various containers within WebLogic Server delegate all authorization and role decisions to the new security framework. The authorization and role-mapping decisions are then delegated to the Service Providers that can be plugged into the security framework by implementing the appropriate Service Provider Interfaces. This mechanism allows the integration of commercial security products so that WebLogic Server can be customized to take advantage of a customer's existing security infrastructure rather than forcing the customer to change.

    Preservation of the developer's experience and allowing J2EE applications that were initially developed for other J2EE implementations to take advantage of the enhanced security functionality found in WebLogic Server 7.0 are critical. As a means to address these goals, the new security architecture supports the ability to consume all previous definitions and assignments contained in deployment descriptors, yet still lets administrators manage role definitions and assignments without editing deployment descriptors.

    Security Auditing
    WebLogic Server 7.0 can be configured to allow administrators to construct security audits for their systems. By default, it is configured to audit authentication attempts, access attempts, security management modifications, and other significant security events. It is not only possible to see which user was attempting access to a specific resource, but also to find out the parameters of that request. Administrators can use the BEA-supplied Auditing plug-in, which creates an audit record for login and access failures along with security management changes. More sophisticated auditing schemes can be implemented using third-party auditing tools. As with the other security provider plug-ins, administrators can configure multiple Auditing plug-ins and set various conditions for their use. This offers administrators fine-grained control over when and whether to take action on an event.

    Connection Filter
    WebLogic Server 7.0 also provides administrator control over permissions to establish a connection to the server. The Connection Filter feature allows enforcement of rules that govern whether a connection should be established based on client IP access or protocol. This capability can be used to restrict the location from which connections to the application server are made, enhancing security of the application. Connection Filter features are configurable from the Administration Console.

    Attack Counter Measures
    In enterprise applications, denial-of-service and other attacks can render significant damage. WebLogic Server is designed to address certain forms of denial-of-service attacks. From the Administration Console, the administrator can set timeouts and other parameters that will counteract attempts to attack the integrity and availability of the application running on it. In addition, WebLogic Server provides measures to counter both online and offline guessing of users and passwords. Offline password protection is protected through use of encryption and other security techniques specifically targeted to counter dictionary attacks. Counter measures for online password guessing include the ability for administrators to control the number of times a login attempt can fail within a given period of time before the account is disabled or locked out.

    Support for Java Standards
    WebLogic Server 7.0 utilizes the security services of JDK version 1.3 for the Java 2 Platform, Enterprise Edition (J2EE). Like the other J2EE components, the security services are based on standardized, modular components. WebLogic Server utilizes these Java security service methods according to the standard, and adds extensions that handle many details of application behavior automatically, without requiring additional programming.

    WebLogic Server's support for JDK 1.3 security means that application developers can take advantage of Sun Microsystems' latest enhancements and developments in the area of security, thus leveraging a company's investment in Java programming expertise. By following the documented Java standard, WebLogic Server's security support has a common baseline for Java developers. The innovations that WebLogic Server provides rest on the baseline support for JDK 1.3.

    JDK 1.3 Security Packages
    The Java Secure Socket Extension (JSSE)

    JSSE is a set of packages that support and implement the SSL and TLS v1 protocol, making those protocols and capabilities programmatically available. WebLogic Server 7.0 provides Secure Sockets Layer (SSL) support for encrypting data transmitted across WebLogic Server clients, and other servers.

    Java Authentication and Authorization Services (JAAS)
    JAAS is a set of packages that provide a framework for user-based authentication and access control. WebLogic Server uses only the authentication classes of JAAS, as the authorization function is implemented through access control features described earlier in the Authorization section.

    The Java Security Manager
    JSM is the security manager for the Java Virtual Machine (JVM). The security manager works with the Java API to define security boundaries through the java.lang.SecurityManager class, enabling programmers to establish a custom security policy for their Java applications.

    Unified Administration for Security Services
    WebLogic Server 7.0 supports unified administration of security services, through the Administration Console, for third-party and customized security services, as well as for BEA's implementations. The Administration Console is a security command center, providing tabs and tools for functions such as the Role Mapper, the Auditor, the Authenticator, the Authorizer, the Credential Mapper, and the Key Store. For compatibility with earlier WebLogic Server 6.x environments, the Administration Console also provides a Realm function.

    With WebLogic Server 7.0, the Administration Console becomes the central (and the best) tool for creating and modifying the security sections of configuration files and deployment descriptors. Configuration files no longer have clear text passwords. WebLogic Server automatically creates protected passwords when it writes this information to the configuration file. Passwords are created on a per-realm basis.

    The Administration Console also supports configuration and management of the Keystore that stores public and private keys, and of the security store (an embedded LDAP directory server). The Auditing plug-in that keeps a trail of security-related activities performed by users and applications is configured using the Administration Console.

    Security Management and Storage
    Security management in the Administration Console is implemented using the classes of the Java Management Extensions (JMX) package. JMX supports both console and programmatic access to management functions via Management Beans (MBeans). Plug-ins can extend base MBeans to meet their needs. This means that any security function in the Administration Console can be extended. Third-party security vendors or security-specific application programmers can add or replace pages in the Administration Console as desired.

    Also, through a full-power command line or programmatic control, administrators and programmers can develop command scripts or programs that execute multiple security-related operations with WebLogic Server without having to use the Administration Console. While convenient and well suited for individual administration operations, the Administration Console can be too slow for repeatable operations, especially if those can be triggered by some event and need to be executed programmatically.

    Security storage is provided by the Key Store and by the WebLogic Server system data store. The Java standard key store stores public and private keys with encrypted storage. The WebLogic Server system data store is an embedded LDAP directory server optimized for use within WebLogic Server 7.0. The system data store provides unified storage (per security realm) of security information and proof material for users, groups, roles, and policies. Customers can also use an existing LDAP directory service for retrieval of storage of user and group information.

    Migrating from WebLogic Server 6.x Security to 7.0 Security
    Customers who installed security under WebLogic Server 6.x have three choices for transitioning to WebLogic Server 7.0:

  • Running in "native" mode: Converting completely to WebLogic Server 7.0 security
  • Running in "compatibility" mode using the Realm Adapter: Supports only existing 6.x security features
  • Running in "mixed" mode: Using the Authorization service of WebLogic Server 7.0 while retaining the 6.x authentication service

    Because of the significant changes in how security is provided in WebLogic Server 7.0, a set of specialized adapters, called "realm adapters," are also provided that allow security realm implementations from previous releases of WebLogic Server to be utilized with the new security framework. The realm adapters permit the use of authentication and authorization capabilities found in WebLogic Server 6.x realm implementations and currently are used to support integration with NT domains and Unix security systems.

    An Export utility (not part of WebLogic Server 7.0, but provided on BEA dev2dev Online at enables customers to extract users (but not passwords), groups, and ACLs from WebLogic Server 6.x and import the information into the embedded LDAP Directory Server in WebLogic Server 7.0.

    WebLogic Server's open, flexible security architecture delivers advantages to all levels of users and introduces an advanced security design for application servers. WebLogic Server 7.0 provides out-of-the-box implementations for each of the security SPIs. Companies now have an application server security solution that, together with clear and well-documented security policies and procedures, can assure the confidentiality, integrity and availability of the server and its data. As a result,
    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

  • 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.