For example, a system administrator might use a Web console that accesses legacy applications through a set of stateless services, to facilitate management. With this approach, the data, which pops up on a browser, is totally unavailable to the outside world because the system administrator’s network is protected. Even though the lines aren’t locked down per se, the communications are locked down by virtue of the users involved and the limited scope of the network.

2. Open/stateless with lines locked down: To remove the risky assumption of a safe network, you need to add a layer of security by, at minimum, locking down your lines. You still indirectly access the mainframe through a set of stateless proxy services in the same way as previously mentioned, with the services opening and controlling the sessions to the mainframe. With this method, line security, via Secure Sockets Layer (SSL) or equivalent, is introduced (see Figure 2).

 

While this change seems simple, it significantly contributes to the usefulness of an SOA. The SOA is distributed; locking down line communications at the application-to-service and service-to-service client removes restrictions on the location of the service client or user.

Advantage: With this approach, you get flexible services that leverage needed parts of your legacy applications. The services are also fast because their session to the mainframe application can be established before they make themselves available for use. That way, the clients of the services can access mainframe assets without waiting for session creation. This approach also lets you extend the use of services to remote locations while ensuring safe data delivery. Your services can enforce legacy authentication as part of their use.

Disadvantage: Stateless application use implies that the mainframe or its applications don’t directly know who their users are. Any authentication happens in the mid-tier infrastructure, or not at all. Although lines are locked down and the service might have authentication that points to Active Directory, for example, there could still be a possible security loophole; when legacy assets are unaware of their use, audit concerns can arise. This method requires a trust relationship with the mid-tier service clients.

Appropriate use: When the application extends beyond the safe network zone, this approach works well, as long as usage of the application services is known and trusted. The assumption is also that the services are visible and available only to those who have the right to use them. Even without explicit protection or tracking of service usage, the services aren’t expected to be able to perform harmful activities; their use is innocuous.

If you have complete control of business data and logic in your enterprise, you can implement stateless access and lock down lines as you see fit. If your usage extends beyond the glass house, and you’re opening mainframe applications to trusted session pools or trusted external sources, this method also might be adequate.

3. Stateless with logging in place: Organizations needing more stringent security measures might consider adding a security log to methods 1 or 2. With this approach, you match service clients to service sessions for application access. This is easily implemented with available service-creation applications. Using logs stored on the mid-tier and controlled by service-wrapping technologies, user identities are recorded and matched to the use of the host application services when they’re invoked. With services using established session pools, multiple users can call to get server-controlled, dedicated sessions in a many-to-one relationship (see Figure 3).

The stateless model with logged service use works best for a true SOA, but still contains risk from a mainframe perspective. When you create wrappered services where use is controlled by the mid-tier, you need a trusted infrastructure in front of the mainframe. SOA governance, combined with service-use logging, helps mitigate the risk. In this scenario, the mainframe itself isn’t required to know who’s gaining access because the mid-tier is recording user credentials and actions.

6 Pages