This proposal has been withdrawn.
Security Runtime for SOA Infrastructures (secRT) is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope of a proposed RT Project called secRT. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the secRT forum.
In business projects companies are confronted with the challenge to map business processes via a number of systems, platforms, applications and networks. In order to guarantee security, different solutions are required. Confidentiality, integrity and authenticity of information and data have to be ensured as well as protection against Trojans, viruses, web attacks and much more. The implementation and integration of different solutions in new infrastructures and processes is one of the main tasks.
A popular approach is the manual implementation of security requirements where they are needed - inside the applications. This - application centric - approach is conventional, but bears considerable risks.
One risk of security inside applications is the loss of orchestration and choreography of these services. This flexibility which e.g. an ESB provides for "Business Services", is missing for security services, which are implemented application centric.
Furthermore, mostly infrastructural security requirements are challenges in projects. The implementation of XML encryption and XML signature may serve as an example. The implementation can be done while the standards are commonly known. But this implementation has to be done for several distributed services - this approach is tedious. And the question arises: how is this process to be automated?
One basic approach for a comprehensive automated solution is to realize a platform independent runtime environment for security. Common services like user-, rights- and role administration as well as automatisms for policy enforcement and administration may be provided via the runtime environment. Applications may use these security services via interfaces without developing own mechanisms for each application.
The secRT uses an architecture consisting of local runtime components (Connector), which act as Policy Enforcement Points. These realize security rules on the systems and provide capsulated security services. A Workflow Engine enables realization of the workflow sequence defined by a local Workflow Editor. Security functionality integrated via adapter may be configured in a process logic and realized accordingly.
Description (scope and goals)
- Provide a Security Runtime (secRT) based on OSGi
- Provide an extension API to extend the secRT with security services (adapter)
- Provide an Security Workflow Editor to orchestrate the security services
- Provide adapters (Bundles, Plug-ins), based on the secRT, that consist of specific security services
- Provide documentation and sample scenarios for the use of secRT and adapters
(1) Provide a Security Runtime (secRT) based on OSGi
Configured and running instances of the secRT (called Security Connectors) act as local Policy Enforcement Points. A Connector automates the security workflows and provides modeled security services. For local administration each connector provides a web interface, where a local Workflow Editor may be used for easy definition of security processes.
The internal services (and so the functionality) may be structured as follows:
As a runtime environment for security applications the secRT provides a multitude of basic security functions which may also be used by other services and applications.Cryptography Algorithms & Basic Security
Standard implementations of algorithms for cryptographic operations are available throughout the entire secRT. Common hashing- and encryption methods may be used easily. The encapsulation of cryptographic libraries (e.g. Bouncy castle) via a wrapper enables easy exchange of libraries. Advantage here is the easy adaptability to appropriate security requirements as well as to export restrictions.Logging
Especially in distributed systems a standardized logging is the prerequisite for efficient system maintenance. For each component secRT provides a logging on basis of Log4J. Daily rolling log-files enable analyses and error search.
Automation LayerBasic Automation
Compared to manual implementation, automation functions are a major advantage of a secRT. In distributed systems an efficient operation is achieved by use of automation. Configuration, deployment and realization may be done without programming effort.Workflow Editor and Engine
Instead of manual programming security functionality, a Workflow Editor provides a modeling approach on basis of existing security services for security processes.Policy Service
During runtime the secRT automatically enforces the security policy. The Connector is able to run as a proxy as well as a separate security service just by changing the security policy rules.Infrastructure Layer
The secRT is based on the OSGI-Framework. In combination with core components the OSGI Framework forms the infrastructure basis.
The OSGI Framework provides the basis for the adapter concept and enables e.g. the dynamic download of functionality during runtime.onASConsole
The onASConsole is the web based secRT administration interface, which enables e.g. the status control of the loaded OSGi bundles. Additionally the secRT is administrated via the onASConsole. The onASConsole also provides the anchor point for the Workflow Editor.Network and Basic Infrastructure
Many SOA implementations are based on common network technologies. The secRT - equally to leading SOA solutions - uses these standards and directly implements the support for http, http(s) and XML/SOAP. Furthermore, required auxiliary functions like http-wrapper, object-handler, proxies, etc. are provided, which enable integration of conventional solutions into the secRT. Other open source projects can be integrated.Adapter Handling
To fulfill the requirements regarding flexibility and adaptability in a security environment, the secRT provides an adapter concept. Adapter may be loaded into the system via an Adapter Loader and then are available immediately. Adapter integrate several bundles in a logical context.
(2) Provide an extension API to extend the secRT with security services (adapter concept)
Via the adapter concept the secRT is completely expandable. Via adapter all functionality is available as services. Aside from using standard adapters, also the individual adjustment resp. composition of functionality is possible. Using the adapter concept even individual security requirements may be realized efficiently. The Adapter Loader of the secRT enables import and management of the adapter.
An adapter contains the code for execution of the services as well as additional description files, workflows and parts of the security policies.
Adapter code may be loaded and administrated dynamically during the runtime. OSGi enables this dynamic concept. OSGi provides a complete life cycle for services and is used in many Eclipse projects. Thus, also services from other projects may be used with minimum effort.
(3) Provide a Security Workflow Editor to orchestrate the security services
With the Workflow Editor the secRT provides a powerful tool, which enables the design of security processes without programming effort. Security methods and standards are turned into a security and decision process with just a few mouse clicks.
The services integrated via adapter are made available via plug-in components.
Process designer and security architects obtain simple tools for realizing security requirements. Additionally to the realization of security methods and standards the Workflow Editor provides a multitude of native functions, which process message transformations or enable Threat Notification and Error Handling.
The result is a consistent security process which is transparently applied to existing services.
The parameterization of services and creation of the policy is html-based. Automatically generated entry masks enable comfortable definition of variables.
(4) Provide adapters (Plug-ins), based on the secRT, that consist of specific security services
To enable direct usage of the secRT, also ready-to-go adapters will be made available within this Open Source project.
A first adapter will be a SOA Security Adapter, which contains the standard SOA security algorithms like WS-Security and SAML as well as the appropriate workflows. Supported by this adapter the secRT may be used as proxy or as service provider. So applications may be enhanced with SOA security automatisms.
(5) Provide documentation and sample scenarios for the use of secRT and adapters
For potential secRT users the introduction to the adapter development and the secRT adjustment should be kept as simple as possible. Therefore, detailed documentation on developer level and especially on user and administrator level should be provided. This will involve user guides, reference guides, operating manuals and tutorials.
We propose that this project should be conducted as a technology project rather than as a part of the Eclipse platform. Being a technology project, it leaves room for experimenting without disrupting other Eclipse platform development work.
Suggested Project Lead and committersThe proposed "Security Runtime (secRT)" project will be initially made up of 3 members.
- Elmar Eperiesi-Beck (CORISECIO; beck at corisecio.com): Project lead
Elmar Eperiesi-Beck was employed at IBM after his degree as Master of Business Informatics. As co-founder of CORISECIO he is working there as Managing Director.
- Alexei Bratuhin (CORISECIO; bratuhin at corisecio.com): Initial committer
- Denis Endro (CORISECIO; endro at corisecio.com): Initial committer
The submitters of this proposal welcome interested parties to post to the forum and request to be added to the list as interested parties or to suggest changes to this document.
- Oliver Wolf - Sopera
- Paul Trevithick - Eclipse Higgins project
- Eclipse Higgins project
- Eclipse Swordfish project
CORISECIO GmbH will contribute major parts of its custom-developed security platform into this project. The contributed code contains the initial code representing the framework and a SOA Security Adapter (Plug-in).
Relationship with other Eclipse Projects
- Equinox: From the infrastructure point of view the secRT consists of OSGi Bundles and so may be used within the Equinox system. Within the secRT project strict attention will be paid to ensure complete compatibility with Equinox at all times.
- Higgins - The Trust Framework: Higgins is an extendable, platform and protocol independent identity solution. A generic support should be given considering the fact that the secRT is also based on open standards. The support will be expanded and ensured throughout the secRT project. Even today some secRT-Components (e.g. Cardspace Selector) are part of the Higgins project and CORISECIO is working close together with the Higgins-Team.
- SOA Runtime Framework (Swordfish): Swordfish is supported as one of the central SOA runtime environments. The use of secRT as swordfish security layer is under evaluation.
Assuming a start of the orientation period in April 2010, the following milestones are planned:
|September 2010||V0.8||Basic framework|
|November 2010||V0.9||SOA Security Adapter|
Initial Eclipse.org presence in April 2010
- Establish CVS repository
- Establish Bugzilla repository
Initial Eclipse.org release, v0.8: September 2010, including:
- Initial version of the secRT - including the basic framework
- Open APIs permitting integration via external adapters
- Initial installation and user documentation, taken from existing (non-public) documentation
Second Eclipse.org release, v0.9: November 2010, including:
- SOA Security Adapter with major SOA Security Support
- Additional adapters to enhance the scope of applications
- Enhanced functionality of the secRT
- Integrating with major eclipse projects
- Implement multiple security standards