Last week I wrote about the criteria we used to design and implement 2E functions as web services, making sure that we followed the principles of service oriented architecture (SOA).
Having confidence that we could structure programs to operate in a common manner, be interoperable, have a single responsibility, etc., gave us a positive feeling as we took on the thorny topic of security.
The web services we were creating would mean that the IBM i would be connected to the internet to allow the client application to pass information up and down. Security doesn't get more important than this, and the answers which we came up with would need to stand up to scrutiny.
Layers, transports and endpoints
Strong security begins with layers, and we knew from past experience that there were a couple of fundamental things which we could do to immediately limit the exposure of our web services.
We knew exactly which servers we wanted to allow into our network from the outside world, with the help of the networks team we used the corporate firewall to filter out any web service calls which were not from the servers which we trusted.
Purchasing and installing a SSL certificate on the IBM i meant that we could ensure that information passing between the IBM i web service server and it's client was wrapped in a HTTPS blanket. What is more, we could choose to extend SSL to be 2-way by exchanging certificate information for parties on both ends of the conversation.
With the size of our "attack surface" greatly reduced we were feeling secure enough to allow access to the development IBM i and begin to develop the application. We knew, however, that there were more layers which we needed to add which would give us the ability within the application to control who was allowed to access data using the web services.
Service Security
Locking down the origin of web service requests and making sure that the information could not be read over the internet would block outsiders from our web services, but what about the "insiders"? Users of the web services still needed to be screened, grouped and recognised to control the manner in which they interacted with the application which sat behind the web services. As was the case with understanding how to make use of SOA, we did some homework.
The Open Web Application Security Project, (OWASP), is a free and open application security community. They are located online at http://www.owasp.org where information is exchanged via their excellent Wiki site. Interestingly, OWASP Wiki pages are always viewed using HTTPS, security is a serious business for these people, whatever the application.
As with our use of SOA, it was helpful to have a checklist of security principles which we could use to guide our choices and review the results. OWASP has such a list.
- Apply defense in depth
- Use a positive security model
- Fail securely
- Run with least privilege
- Avoid security by obscurity
- Keep security simple
- Detect intrusions
- Don’t trust infrastructure
- Don’t trust services
- Establish secure defaults
For our project we made use of the OWASP Development Guide to familiarize ourselves with the threats which are out there and best practice for protecting against them. We also went back to the book SOA Patterns by Thomas Erl, and were able to tie in the application of the OWASP best practices to the definitions of the service integration security patterns (Erl : Chapter 20), and settled on an implementation of the brokered authentication pattern within our 2E application.
Brokered authentication works on the principle that the user of the web service provides valid security credentials and in return receive a token which they can use to make further requests for a defined period. The token has intrinsic value for application developers because the web service can use the value of the token to identify the user and other information which can be used by the application to control how the web service responds to the request.
Application Control
Applying our understanding to programs written using CA 2E was the next step. Our work do date with the Integrated Application Server (IAS) on the IBM i meant that we already knew that the features offered by the server were, as described by IBM, "lightweight". In practice what this means is that features are not available to process things like authentication, session, and reliable messaging, all of which are standard on IBM's WebSphere Application Server (WAS).
Did these restrictions mean that we would need to pay for WAS if we wanted security and session support for our web services? Well, as it turns out, no. We found that we could build these features into the 2E code quite easily, and in doing so put more information and control into the hands of the 2E application developers.
Using CA 2E we created a suite of new files which modelled the relationship between users, user groups, and the programs that were permitted to be run. We then defined some core services which could authenticate users before they were permitted to access our application web services, this followed the brokered authentication pattern we had researched. We made use of the cryptographic API on the IBM i to make sure that we used industrial strength algorithms to hash sensitive information. We took direction from OWASP to make sure that our choices about key and token size and lifetime followed best practice.
The main services invloved in the 2E web services application. (Click to enlarge).
This wasn't the first web application that the team had worked on, and so we also knew the value in building monitoring and audit features from the outset. The most significant for the application which we were writing was support for a "heartbeat" which allowed service users to monitor the health of the iSeries as well as report that all was well with them. This feature allows us to send notifications to support staff when communication is lost between the two ends of the conversation, something which has already proved invaluable in the live environment.
We wanted to make the process of writing the 2E programs which would perform the application processing as straightforward as possible for the development team. Using 2E function templates feature we produced a blueprint for all application services which included a standard input parameter of the security token, and a call to a central validation function which encapsulated all security and control logic. A 2E developer creating a new service program would make use of the template, add their own additional parameters and then put their own action diagram code after the security check in the knowledge that it would only be executed if the user was correctly authorised.
Now Build Applications!
With a little research and knowledge we were able to implement layers of security which allowed us to connect our 2E web services to other trusted parties via the internet. Development of the security framework described here was acomplished using standard 2E programming techniques. We made use of the IBM security API via some RPGIV user source, all other coding was done in the action diagram editor.
The framework allows 2E developers to concentrate on writing application logic without needing to get involved in the details of security. It also means that security is implmented consistently across all of the web services written and published using 2E.
With the first project now live we are looking at a number of other business applications which will make use of web services. The 2E team are going to be kept busy because there is a high demand for integration with other platforms using this technology.
Further posts on the adoption of SOA and creation of web services using CA 2E will follow. Look at this page for updates.
Matthew Morris is a developer and director at Desynit. Desynit works with companies around the world, looking to improve the business benefits of their existing systems, with lower costs and less risk. If you are interested in knowing more about this topic, or have comments, contact the author via email matthew.morris@desynit.com