secrt/proposal.html - www.eclipse.org/proposals - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
         "http://www.w3.org/TR/html4/strict.dtd">

 <html>

 <head>

 <title>secRT</title>

 </head>

 <body>

 <h2>
 Introduction
 </h2>
 <p>
 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 <a href="http://www.eclipse.org/forums/eclipse.secrt">secRT forum</a>.
 </p>

 <h2>
 Background
 </h2>
 <p>
 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.
 </p>

 <p>
 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.
 </p>

 <p>
 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.
 </p>

 <p>
 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?
 </p>

 <p>
 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.
 </p>

 <p>
 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.
 </p>

 <h2>
 Description (scope and goals)
 </h2>
 <h3>
 Proposed components
 </h3>
 <p>
 <ol>
 <li>Provide a Security Runtime (secRT) based on OSGi </li>
 <li>Provide an extension API to extend the secRT with security services (adapter)</li>
 <li>Provide an Security Workflow Editor to orchestrate the security services</li>
 <li>Provide adapters (Bundles, Plug-ins), based on the secRT, that consist of specific security services </li>
 <li>Provide documentation and sample scenarios for the use of secRT and adapters</li>
 </ol>
 </p>
 <h4>
 (1)	Provide a Security Runtime (secRT) based on OSGi
 </h4>

 <p>
 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.
 </p>

 <p>
 The internal services (and so the functionality) may be structured
 as follows:
 </p>
 <img src="img/internalservices.jpg" alt="internal services" width="50%">
 <p>
 <b>Security Layer</b>
 </p>

 <p>
 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.
 </p>

 <b><i>Cryptography Algorithms & Basic Security</i></b>

 <p>
 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.
 </p>

 <b><i>Logging</i></b>

 <p>
 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.
 </p>

 <p>
 <b>Automation Layer</b>
 </p>

 <b><i>Basic Automation</i></b>

 <p>
 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.
 </p>

 <b><i>Workflow Editor and Engine</i></b>

 <p>
 Instead of manual programming security functionality, a Workflow
 Editor provides a modeling approach on basis of existing security
 services for security processes.
 </p>

 <b><i>Policy Service</i></b>
 <p>
 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.
 </p>

 <b>Infrastructure Layer</b>
 <p>
 The secRT is based on the OSGI-Framework. In combination with core
 components the OSGI Framework forms the infrastructure basis.
 </p>

 <p>
 The OSGI Framework provides the basis for the adapter concept and
 enables e.g. the dynamic download of functionality during runtime.
 </p>

 <b><i>onASConsole</i></b>
 <p>
 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.
 </p>

 <b><i>Network and Basic Infrastructure</i></b>

 <p>
 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.
 </p>

 <b><i>Adapter Handling</i></b>

 <p>
 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.
 </p>

 <h4>
 (2)	Provide an extension API to extend the secRT with security services (adapter concept)
 </h4>

 <p>
 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.
 </p>

 <p>
 An adapter contains the code for execution of the services as well as additional description files, workflows and parts of the security policies.
 </p>

 <p>
 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.
 </p>

 <h4>
 (3)	Provide a Security Workflow Editor to orchestrate the security services
 </h4>

 <p>
 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.
 </p>

 <img src="img/workfloweditor.jpg" alt="Workflow Editor">

 <p>
 The services integrated via adapter are made available via plug-in components.
 </p>

 <p>
 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.

 <p>
 The result is a consistent security process which is transparently applied to existing services.
 </p>

 <p>
 The parameterization of services and creation of the policy is html-based. Automatically generated entry masks enable comfortable definition of variables.
 </p>

 <img src="img/parameterization.jpg" alt="Workflow Editor">

 <h4>
 (4)	Provide adapters (Plug-ins), based on the secRT, that consist of specific security services
 </h4>

 <p>
 To enable direct usage of the secRT, also ready-to-go adapters will be made available within this Open Source project.
 </p>

 <p>
 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.
 </p>

 <h4>
 (5)	Provide documentation and sample scenarios for the use of secRT and adapters
 </h4>

 <p>
 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.
 </p>

 <h2>
 Organization
 </h2>
 <p>
 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.
 </p>

 <h3>Suggested Project Lead and committers</h3>
 The proposed "Security Runtime (secRT)" project will be initially made up of 3 members.
 <ul>
 <li>Elmar Eperiesi-Beck (CORISECIO; beck at corisecio.com): Project lead<br>
 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.</li>
 <li>Alexei Bratuhin (CORISECIO; bratuhin at corisecio.com): Initial committer</li>
 <li>Denis Endro (CORISECIO; endro at corisecio.com): Initial committer</li>
 </ul>

 <p>
 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.
 </p>

 <h2>
 Mentors
 </h2>
 <p>
 <ul>
 <li>Oliver Wolf  - Sopera </li>
 <li>Paul Trevithick - Eclipse Higgins project</li>
 </ul>
 </p>

 <h2>
 Interested Parties
 </h2>
 <ul>
 <li>Sopera</li>
 <li>Aziego</li>
 <li>Eclipse Higgins project</li>
 <li>Eclipse Swordfish project</li>
 </ul>

 <h2>Code Contribution</h2>

 <p>
 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).
 </p>

 <h2>Relationship with other Eclipse Projects</h2>
 <ul>
 <li><b>Equinox</b>: 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.</li>
 <li><b>Higgins - The Trust Framework</b>: 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.</li>
 <li><b>SOA Runtime Framework (Swordfish)</b>: Swordfish is supported as one of the central SOA runtime environments. The use of secRT as swordfish security layer is under evaluation.</li>
 </ul>

 <h2>Tentative Plan</h2>
 <p>
 Assuming a start of the orientation period in April 2010, the following milestones are planned:
 </p>

 <table border="1">
 <tr><td><i>Milestone</i></td><td><i>Version</i></td><td><i>Deliverable/Scope</i></td></tr>
 <tr><td>September 2010</td><td>V0.8</td><td>Basic framework</td></tr>
 <tr><td>November 2010</td><td>V0.9</td><td>SOA Security Adapter</td></tr>
 </table>

 <p>Initial Eclipse.org presence in April 2010</p>
 <ul>
 <li>website</li>
 <li>newsgroup</li>
 <li>Establish CVS repository</li>
 <li>Establish Bugzilla repository</li>
 </ul>

 <p>Initial Eclipse.org release, v0.8: September 2010, including:</p>
 <ul>
 <li>Initial version of the secRT - including the basic framework</li>
 <li>Open APIs permitting integration via external adapters</li>
 <li>Initial installation and user documentation, taken from existing (non-public) documentation</li>
 </ul>

 <p>Second Eclipse.org release, v0.9: November 2010, including:</p>
 <ul>
 <li>SOA Security Adapter with major SOA Security Support</li>
 </ul>

 <h2>Outlook</h2>
 <p>
 <ul>
 <li>Additional adapters to enhance the scope of applications</li>
 <li>Enhanced functionality of the secRT</li>
 <li>Integrating with major eclipse projects</li>
 <li>Implement multiple security standards</li>
 </ul>
 </p>

 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
	"http://www.w3.org/TR/html4/strict.dtd">

	<html>

	<head>

	<title>secRT</title>

	</head>

	<body>

	<h2>
	Introduction
	</h2>
	<p>
	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 <a href="http://www.eclipse.org/forums/eclipse.secrt">secRT forum</a>.
	</p>

	<h2>
	Background
	</h2>
	<p>
	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.
	</p>

	<p>
	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.
	</p>

	<p>
	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.
	</p>

	<p>
	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?
	</p>

	<p>
	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.
	</p>

	<p>
	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.
	</p>

	<h2>
	Description (scope and goals)
	</h2>
	<h3>
	Proposed components
	</h3>
	<p>
	<ol>
	<li>Provide a Security Runtime (secRT) based on OSGi </li>
	<li>Provide an extension API to extend the secRT with security services (adapter)</li>
	<li>Provide an Security Workflow Editor to orchestrate the security services</li>
	<li>Provide adapters (Bundles, Plug-ins), based on the secRT, that consist of specific security services </li>
	<li>Provide documentation and sample scenarios for the use of secRT and adapters</li>
	</ol>
	</p>
	<h4>
	(1) Provide a Security Runtime (secRT) based on OSGi
	</h4>

	<p>
	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.
	</p>

	<p>
	The internal services (and so the functionality) may be structured
	as follows:
	</p>
	<img src="img/internalservices.jpg" alt="internal services" width="50%">
	<p>
	<b>Security Layer</b>
	</p>

	<p>
	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.
	</p>

	<b><i>Cryptography Algorithms & Basic Security</i></b>

	<p>
	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.
	</p>

	<b><i>Logging</i></b>

	<p>
	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.
	</p>

	<p>
	<b>Automation Layer</b>
	</p>

	<b><i>Basic Automation</i></b>

	<p>
	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.
	</p>

	<b><i>Workflow Editor and Engine</i></b>

	<p>
	Instead of manual programming security functionality, a Workflow
	Editor provides a modeling approach on basis of existing security
	services for security processes.
	</p>

	<b><i>Policy Service</i></b>
	<p>
	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.
	</p>

	<b>Infrastructure Layer</b>
	<p>
	The secRT is based on the OSGI-Framework. In combination with core
	components the OSGI Framework forms the infrastructure basis.
	</p>

	<p>
	The OSGI Framework provides the basis for the adapter concept and
	enables e.g. the dynamic download of functionality during runtime.
	</p>

	<b><i>onASConsole</i></b>
	<p>
	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.
	</p>

	<b><i>Network and Basic Infrastructure</i></b>

	<p>
	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.
	</p>

	<b><i>Adapter Handling</i></b>

	<p>
	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.
	</p>

	<h4>
	(2) Provide an extension API to extend the secRT with security services (adapter concept)
	</h4>

	<p>
	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.
	</p>

	<p>
	An adapter contains the code for execution of the services as well as additional description files, workflows and parts of the security policies.
	</p>

	<p>
	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.
	</p>

	<h4>
	(3) Provide a Security Workflow Editor to orchestrate the security services
	</h4>

	<p>
	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.
	</p>

	<img src="img/workfloweditor.jpg" alt="Workflow Editor">

	<p>
	The services integrated via adapter are made available via plug-in components.
	</p>

	<p>
	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.

	<p>
	The result is a consistent security process which is transparently applied to existing services.
	</p>

	<p>
	The parameterization of services and creation of the policy is html-based. Automatically generated entry masks enable comfortable definition of variables.
	</p>

	<img src="img/parameterization.jpg" alt="Workflow Editor">

	<h4>
	(4) Provide adapters (Plug-ins), based on the secRT, that consist of specific security services
	</h4>

	<p>
	To enable direct usage of the secRT, also ready-to-go adapters will be made available within this Open Source project.
	</p>

	<p>
	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.
	</p>

	<h4>
	(5) Provide documentation and sample scenarios for the use of secRT and adapters
	</h4>

	<p>
	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.
	</p>

	<h2>
	Organization
	</h2>
	<p>
	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.
	</p>

	<h3>Suggested Project Lead and committers</h3>
	The proposed "Security Runtime (secRT)" project will be initially made up of 3 members.
	<ul>
	<li>Elmar Eperiesi-Beck (CORISECIO; beck at corisecio.com): Project lead<br>
	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.</li>
	<li>Alexei Bratuhin (CORISECIO; bratuhin at corisecio.com): Initial committer</li>
	<li>Denis Endro (CORISECIO; endro at corisecio.com): Initial committer</li>
	</ul>

	<p>
	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.
	</p>

	<h2>
	Mentors
	</h2>
	<p>
	<ul>
	<li>Oliver Wolf - Sopera </li>
	<li>Paul Trevithick - Eclipse Higgins project</li>
	</ul>
	</p>

	<h2>
	Interested Parties
	</h2>
	<ul>
	<li>Sopera</li>
	<li>Aziego</li>
	<li>Eclipse Higgins project</li>
	<li>Eclipse Swordfish project</li>
	</ul>

	<h2>Code Contribution</h2>

	<p>
	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).
	</p>

	<h2>Relationship with other Eclipse Projects</h2>
	<ul>
	<li><b>Equinox</b>: 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.</li>
	<li><b>Higgins - The Trust Framework</b>: 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.</li>
	<li><b>SOA Runtime Framework (Swordfish)</b>: Swordfish is supported as one of the central SOA runtime environments. The use of secRT as swordfish security layer is under evaluation.</li>
	</ul>

	<h2>Tentative Plan</h2>
	<p>
	Assuming a start of the orientation period in April 2010, the following milestones are planned:
	</p>

	<table border="1">
	<tr><td><i>Milestone</i></td><td><i>Version</i></td><td><i>Deliverable/Scope</i></td></tr>
	<tr><td>September 2010</td><td>V0.8</td><td>Basic framework</td></tr>
	<tr><td>November 2010</td><td>V0.9</td><td>SOA Security Adapter</td></tr>
	</table>

	<p>Initial Eclipse.org presence in April 2010</p>
	<ul>
	<li>website</li>
	<li>newsgroup</li>
	<li>Establish CVS repository</li>
	<li>Establish Bugzilla repository</li>
	</ul>

	<p>Initial Eclipse.org release, v0.8: September 2010, including:</p>
	<ul>
	<li>Initial version of the secRT - including the basic framework</li>
	<li>Open APIs permitting integration via external adapters</li>
	<li>Initial installation and user documentation, taken from existing (non-public) documentation</li>
	</ul>

	<p>Second Eclipse.org release, v0.9: November 2010, including:</p>
	<ul>
	<li>SOA Security Adapter with major SOA Security Support</li>
	</ul>

	<h2>Outlook</h2>
	<p>
	<ul>
	<li>Additional adapters to enhance the scope of applications</li>
	<li>Enhanced functionality of the secRT</li>
	<li>Integrating with major eclipse projects</li>
	<li>Implement multiple security standards</li>
	</ul>
	</p>

	</body>
	</html>