The first part of the Enterprise SOA Security series deals with the challenges of contemporary IT landscapes. For example, BYOD, cross-departmental solutions, company-wide workflows and the opening of core systems for customers and suppliers frequently overburden traditional security solutions which were designed for less distributed application silos more than a decade ago.
Enterprise SOA Security – Part 2: Solution Patterns
Solution patterns, which help to design modern SOA security, are introduced in the second part of the series. Here, the focus lies on security tokens, which ensure that every component can make secure assumptions about its users and their authorization profiles in a distributed environment.
Furthermore, the article depicts the main architecture elements such as identity providers, secure token services, or rule engines as well as their typical interactions.
Enterprise SOA Security – Part 3: Web Services Standards
Countless Web Services standards such as SAML, WS Security, XACML or WS Trust help with the implementation of interoperable security solutions in a service-oriented architecture. The third part of the article series provides an overview of the existing standards and their practical use.
Enterprise SOA Security – Part 4: Organizational Measures
SOA Security is hardly a technology subject only. Cross-departmental processes and role concepts also require cross-departmental governance and a change of thinking in the risk departments of large companies.
XML Gateways Facilitate Centralized API Security
The given article sketches out a best practice to implement a company-wide security strategy for cross-departmental and cross-company Web Services communication. One of the key proposals is the centralization of security functionality with XML Gateways (aka API Gateways). It highlights crucial features such as:
- Service virtualization
- Privacy and integrity
- Control and auditing of data flows
Furthermore, this article describes critical success factors and possible practical approaches for the implementation in detail.
Safe In The Cloud: Cross-Company Security Best Practices
Extending the ideas of enterprise IT to cross-company communication and in particular to the use of shared services, which are no longer found in a single data centre, one enters today’s most discussed field under the term “Cloud”.
Many of the security recommendations that apply within the boundaries of an individual company also apply to the Cloud. As the company’s boundaries will be transgressed a diversity of additional requirements arises inevitably.
Centralized Security Outperforms Decentralized Approaches in Practice
This article compares centralized and decentralized security implementations in large application landscapes – particularly focusing on costs and organizational challenges. With a closer inspection it becomes clear that centralized security implementations have significant advantages over decentralized ones. Those advantages make it very attractive for large corporations to resist the typical tendencies of projects to deliver individual solutions.
APIs and SOA enable enterprises to rapidly exchange data in real-time. The increase of the resulting data traffic and the interconnectivity across company boundaries as well as cloud based services provide a multitude of opportunities for enterprises to reduce their process cost and increase benefits and user-friendliness of IT applications.
Major projects that provide or consume APIs increasingly have to cope with security aspects of the APIs. They have to test not only functional behavior of the APIs but also security specifications. Enterprises currently learn that security testing has many sophisticated aspects going far beyond the challenges associated with traditional functional tests.
It is therefore key for the long-term success of business critical APIs that expert teams ensure security standards based on rigid processes and powerful testing tools.
Mobile App Development
The elegance of many mobile applications in the mobile and game field encourages people to playfully approach the development of mobile business processes. However, practice shows that there are no magic shortcuts for mobile software projects. Serious requirements management, robust software design and a well-considered architecture are just as important for the success of mobile projects as for other projects in the corporate architecture. In addition to the traditional design disciplines, a mobile project must address the exceptional needs of graphical user interface design and interaction control.
SSO with SAML – Part 1: Security
Providing legacy applications with SAML can be time consuming and costly. For this reason, API gateways are often used to solve these problems out of the box, avoiding the change of existing applications on the code level and still being able to advance a forward-looking approach based on SAML SSO.
SSO with SAML – Part 2: Implementation
Many companies are faced with the decision of vertical integration in which they want to implement single sign-on (SSO). Central solutions are often too expensive for individual projects, while self-developed solutions have serious disadvantages in the long term. The following aspects should be considered when making an architecture decision:
- Building your own adapters can tie up your development team’s time and resources, which are then lost for professional development.
- The finished adapters require additional bandwidth for ongoing maintenance and troubleshooting.
- Every new or updated service provider has to go through a thorough security check because each service provider has its own target.
- Adapters do not protect the service provider from the dangers of the underlying platform such as insecure SSL implementations.
- The impact of SSO implementation on performance and scalability must be taken into account for each individual service provider.
The decentralized architecture requires strict governance, otherwise it can lead to potential inconsistencies in different environments and can result in significant maintenance efforts.
Case Study: Mobile App for Car Dealers Illustrates Up-to-date Development Practices
SOAPARK’s Asskura Model Supports Strategic Evolution of Insurance IT Landscapes
By no means IT landscapes of insurance companies can be changed easily. It requires long-term efforts and planning to foster a strategic evolution process.
Typically, enterprise architecture and strategy departments are in charge of this process. However, it is not always clear what the right direction for data, processes, and applications evolution is. It is a thorny way but it yields the opportunity to reduce waste, as well as duplicate and implement non-strategic project efforts.
This brochure explains how SOAPARK supports the decision-maker of an insurance company in better managing their IT projects and successfully developing their IT applications. The proposal is based on the usage of a centralized data and process model in addition to six “golden” practices.
SOAPARK Publishes Comprehensive Data and Process Reference Model For The Insurance Industry
SOAPARK’s comprehensive data and process reference model – the Asskura Model – provides a solid foundation for the management and evolution of IT assets plus processes of insurance companies.
The model comprises 24 process domains, 74 main processes, and nearly 1.200 process sequences. The data model is structured by 17 data domains and also covers over 1.100 data objects and more than 600 diagrams.
Start SOA Without the Burden of an Expensive Service Repository
An intelligible service repository is a critical success factor of any enterprise-wide API or SOA initiative. It is inevitably true that managing the portfolio of service endpoints, knowing what the service endpoints are about, and applying design guidelines is pivotal for the success.
However, setting up a repository is a big hurdle for an API or SOA initiative. This is due to the costs, learning curve, or political complexity.
The “Service Planning Sheet” works well as a replacement repository for the starting phase. As long as you have less than 25 services and a maximum of three parallel projects, you can manage your services in Excel spreadsheets which can be embedded in your content management system or shared via file servers. In a later stage the content can be imported without any great difficulty into a professional tool with which you can manage the life cycle of the services.
Standardized Service Specification Facilitated by Free Service Operation Sheet
For every service, one or possibly more operations must be described. This can be done with the “Service Operation Sheet”. It replaces a fully fletched service repository in the start phase of an API or SOA initiative and provides a best practice data model covering all aspects of a service specification including business meaning, technology, input and output data, exceptions and faults, test cases etc.
The sheet ensures that services are designed and documented properly even before a fully fletched SOA governance framework is in place.