IBM’s WebSphere Application Server for eserver iSeries 400 (formerly named WebSphere Application Server for AS/400) is an e-business application deployment environment built on open standards and is available in two editions. The Standard Edition lets you use Java servlets, JavaServer Page (JSP), and XML to quickly add dynamic content to your Web sites. The Advanced Edition offers all of the functionality of the Standard Edition and additionally supports Enterprise JavaBean (EJB) components.
With WebSphere Application Server, you can secure your applications by configuring three security policies: authentication for determining who is making a request, authorization for determining whether the request is to be honored, and delegation for determining who will be handling the request. Security requirements vary by application. WebSphere allows you to tailor your security policies to match the requirements of individual e-business applications. WebSphere authentication and authorization policies apply to both Enterprise JavaBean and Web resources (including HTML files, JSPs, and servlets), and the same tasks configure security for Web resources and EJBs to provide a unified security model. Resources comprising e-business applications are often distributed across multiple application servers, and those servers may be hosted on different systems.
For such topologies, the WebSphere Application Server provides a distributed security model.
In this article, I’ll provide an overview of WebSphere Application Server security. I’ll also provide instructions for configuring security for a simple application and for a few other tasks related to maintenance and administration.
The instructions for configuring security assume a simple topology consisting of one application server and one Web server, both hosted on the same system, and demonstrate how to configure basic security for a Web client. The WebSphere Application Server supports two client types, a Web client and a Java (EJB) client or applet. Implementing security for a Java client is beyond the scope of this article, though, so this won’t be discussed.
The information presented here is specific to WebSphere Application Server Version 3.5. Though much of this information is also applicable to Version 3.0, I will not attempt to deal with all differences between the two releases; I’ll only note some of the major differences.
Getting Secure
Web clients communicate with a Web server using the HTTP protocol. The WebSphere Application Server provides security services to the Web server via a security plug-in. This plug-in serves as an interface to the security application that resides within the administrative server and helps make security decisions when users request HTML files from the Web server. Security services are provided to the application server via a security collaborator, which serves as an interface to the security application. The collaborator makes security decisions on method calls on EJBs, JSPs, and servlets hosted by the application server. Figure 1 demonstrates the interaction between a security application and the security runtime in the application server and the Web server.
Security policies are configured using the WebSphere administrative console, which is a Java client to the administrative and security applications within the WebSphere administrative server.
An authentication policy determines how authentication is accomplished. Authentication is performed in two steps: first, acquiring the authentication data of a principal; second, validating the authentication data against a user registry.
To understand an authentication policy, you first should be familiar with its components. An authentication mechanism validates authentication data against an associated user registry. The WebSphere Application Server offers two choices for authentication mechanisms: Lightweight Third Party Authentication (LTPA) and native OS. LTPA uses a trusted third-party server to authenticate a user. LTPA is the heart of the distributed security model. Since all application servers trust the third-party authentication server, security information can be passed along with requests from one application server to another. Use the LTPA authentication mechanism when applications are distributed across multiple application servers and the application servers are hosted on different systems. The native OS authentication mechanism uses native OS/400 routines (OS/400 user profiles) to authenticate a user. A native OS is easier to configure than LTPA but can be used only when all application servers are hosted by the same system. Note that authenticating through the native OS mechanism does not log a user onto OS/400. Even though user profiles and passwords are used for authentication, no jobs or threads are executed under users’ profiles.
A challenge type specifies how a server will challenge and retrieve authentication data from a user. The choices for challenge type are none, basic, custom, and certificate. With a challenge type of none, a user is not challenged for authentication data. If the requested resource is protected, then the user will not be served the resource. With the basic challenge type, the user is challenged for a user ID and password. The custom challenge type is applicable only to Web clients and is used when one wants to configure the server to use a customized HTML form to retrieve a user ID and password. The certificate challenge is also applicable only to Web clients. In this case, the user is required to present a digital certificate (X.509) to establish a connection. With the certificate challenge type, the Web server is trusted to authenticate a user through the Secure Sockets Layer (SSL) exchange. Then, for authorization purposes, the WebSphere security infrastructure identifies the principal by extracting information from the certificate and mapping it to an entry in the user registry.
A user registry is where user and group information is stored. It contains a mapping of principals to authentication information and privilege attributes, such as user IDs, passwords, and group IDs.
A principal is a representation of a human user or system entity, such as a server process. The choices for user registry are native OS (which takes advantage of OS/400 profiles) and Lightweight Directory Access Protocol (LDAP) OS/400 Directory.
Secure channel constraint requires an SSL protocol session along with a challenge type to provide data confidentiality and integrity for information flowing between the server
and a Web client. Secure channel constraint may be turned on or off. Dependencies limit how components can be used within an authentication policy. In Figure 2 (page 52), the possible combinations are represented.
The authorization policy determines how authorization is accomplished. Authorization consists of two steps: first, creating permissions and assigning those permissions to principals; second, verifying at runtime that the requesting principal holds at least one of the required permissions.
The WebSphere Application Server authorization model is based on the classic capability model, which is different from the access control model. With the capability model, permissions are associated with a principal. In the access control model, principals and the operations they can perform are associated with the resources themselves.
Resources include Web resources and EJBs. Web resources can only be accessed from Web clients, and for security purposes, each Web resource is represented by a Uniform Resource Identifier (URI). In other words, WebSphere security protects the URI. Since it is possible for a physical resource to be mapped by more than one URI, then one URI can be protected while another URI isn’t. To securely protect a physical resource (such as an HTML file), every URI for that resource must be protected.
With WebSphere Application Server Version 3.x, all Web resources can be protected with a single authorization policy. Any resource actually served by a Web server can be protected by the same authorization policy that protects servlets and JSP files that are served by an application server. However, this will not be supported in future releases. To protect Web resources in versions later than 3.x, those resources must be served by the WebSphere Application Server.
WebSphere security is granular to an enterprise bean home, but not to particular enterprise bean instances. For example, AccountBean is an enterprise bean that encapsulates the account information of account holders. A WebSphere administrator grants Bob access to the AccountBean, so Bob has access to every account in the system. It is not possible to specify that Bob should be able to access only his account and not others. This must be accomplished using application logic. An enterprise bean can belong to multiple enterprise applications.
By default, all enterprise beans are protected and no Web resources are protected when security is enabled. So, until authorization policy is configured, no enterprise bean can be accessed, but all Web resources can be accessed by anyone.
A Web application is a group of servlets that share a common servlet context. A Web application can belong to only one enterprise application. All servlets and JSPs belong to a Web application.
An enterprise application is a collection of Web applications, EJBs, and Web server resources. An authentication policy can be tailored to an application by modifying the challenge type and secure channel constraint values in the enterprise application.
A method group is a collection of {resource name, method name} pairs. For a Web resource, the resource name corresponds with the Web resource, as denoted by its URI, and the method name is an HTTP method. For an enterprise bean resource, the resource name corresponds with either the enterprise bean or its home, and the method name is one of the method names of the enterprise bean or its home.
At configuration time, the names of WebSphere resource methods can be used to determine membership in six predefined method groups. For example, if a method is called getName(), it would be added to the ReadMethods method group if the mapping to the default method groups is applied. Alternatively, the administrator can create new method groups and add methods to those method groups. The default method groups are as follows:
• ReadMethods includes all methods of an enterprise bean that have the prefix get; for example, getName (). For a Web resource, ReadMethods includes the HTTP_GET and HTTP_POST methods.
• WriteMethods includes all methods of an enterprise bean that have the prefix set; for example, setName(). For a Web resource, WriteMethods includes the HTTP_PUT method.
• RemoveMethods includes all remove() methods of an enterprise bean Home. For a Web resource, RemoveMethods includes the HTTP_DELETE method.
• CreateMethods includes all create() methods of an enterprise bean Home.
• FinderMethods includes all findXX() methods of an enterprise bean Home.
• ExecuteMethods includes all methods of an enterprise bean that do not fall under any of the aforementioned categories.
For any given WebSphere resource, a method can be associated with multiple method groups, but all methods must be associated with at least one method group.
A permission is a {enterprise application, method group} pair. To be authorized to invoke a method on a resource, a principal must hold a permission associated with both an enterprise application that contains the resource and a method group that contains the method. Permissions are assigned to privilege attributes (user ID or group ID, for example). The user registry maps principals to privilege attributes. A principal is considered to be holding a permission if that permission has been granted to at least one of its privilege attributes. Since permissions are defined by an enterprise application and a method group, authorization policy is implicitly tailored to applications.
To summarize, authorization policies correlate resources with (enterprise) applications and methods with method groups. Principals are granted permissions that result from these associations, and verification is done at runtime to ensure that the requesting principal holds at least one required permission. See Figure 3.
Delegation involves the use of an intermediary to invoke a method on a target resource on behalf of a requesting client. For example, a client invokes a method on a session enterprise bean that, in turn, invokes a method on an entity enterprise bean. The session bean is acting as an intermediary between the client and the entity bean. A delegation policy determines the identity under which the intermediary operates on behalf of the client.
In the WebSphere Application Server, the delegation policy is determined by values associated with the methods of the enterprise bean. The initial values are retrieved from the deployment descriptors of a bean but can later be modified by an administrator. Delegation policies can be applied jointly to all the methods in a bean or separately to individual methods.
A delegation policy is created by setting the values of one (or two) attributes: Run- As Mode or Run-As Identity. The Run-As Mode attribute determines the identity under which methods are to be run. The valid values are CLIENT, SYSTEM, and SPECIFIED. The Run-As Identity attribute specifies the principal when the Run-As Mode is SPECIFIED. This value must be selected by an administrator from an identity associated with one of the enterprise applications that contains the enterprise bean. When the authentication mechanism is native OS, the effective Run-As Mode is always SYSTEM, regardless of the value that is specified. LTPA supports all three values.
To sum up, WebSphere applications can be secured by configuring three policies: authentication, authorization, and delegation. Two authentication mechanisms are offered: native OS and LTPA. The native OS mechanism can only be used when all application servers are hosted by the same system. LTPA is the choice when application servers are hosted by different systems. Authorization is based on the capability model. This differs from the access list model, as permissions are associated with a principal in the capability
model, while in the access control model, principals and the operations they can perform are associated with the resources themselves.
Delegation is defined in terms of the Run-As Mode and Run-As Identity attributes assigned to EJBs. Authentication policy can be partly tailored to an application by modifying the challenge type and secure channel constraint settings for enterprise applications, while authorization policies are implicitly tailored to individual applications. The LTPA authentication mechanism is the heart of the distributed security model, providing a third-party security server that all application servers trust.
This overview, together with the Web sidebar “A WebSphere Configuration Scenario: Configuring Security” (posted at www.midrangecomputing.com/mc), which includes the instructions for enabling security and configuring a simple application, provides you with a good start but only begins to scratch the surface of WebSphere’s security features. Additional topics you may wish to investigate include enabling security for Java clients, single sign-on, HTTP session security, and programmatic support for login.
REFERENCES AND RELATED MATERIALS
• Extending WebSphere Applications for Business-to-Business Integration—AS/400 Edition: www.as400.ibm.com/ebusiness/expreport/wsappextend.htm
• IBM WebSphere page: www.iseries.ibm.com/websphere
• “IBM WebSphere Standard/Advanced 3.5 Security Overview,” Gennaro Cuomo, Don Ferguson, Michael Fraenkel, Rob High, and Nataraj Nagaratnam (available at www.ibm.com/software/webservers/appserv/security_v35.pdf)
Web Client Java Client HTML IIOP
Security Plug-in
Web Server WebSphere Application Server Web Server
Resources
HTML WebSphere
Resources
EJBs Servlets JSPs
Figure 1: Security policies can be configured to protect Web server and WebSphere resources.
OSE
Security Application Security Collaborator
Challenge Authentication User Client Type Mechanism Registry
None None None Web, Java
Basic LTPA LDAP Web, Java
Basic Native OS Native OS Web, Java
Certificate LTPA LDAP Web
Custom LTPA LDAP Web
Figure 2: Dependencies limit how components can be combined to form authentication policies.
Permission
Resource Method
Figure 3: Principals are granted permissions that result from associations involving applications, resources, methods, and method groups.
Principal
Enterprise Application
Method Group
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online