Security concerns of composite systems

For last couple of days I managed to read a bit about composite systems and how useful the component based Software Engineering when it comes to the industry. The flexibility of coupling and decoupling components in a composite systems and reusability of using one component in a number of such systems makes them very attracted in numerous applications.
But at the same time we have to consider about the security concerns in that approach. These concerns can be divided into two categories.

1.Security concerns of the component
2.Security concerns when the component is inegrated and used

When forming or modifying composite systems by coupling and decoupling different components the integrator has to evaluate how the component is secured itself. In other words how securely the component is being built by the developer.
Also the integrator has to evaluate how the system is secured from the components. A set of secure components doesn’t always guarantee a secure system. The integrator has to determine for what extent the system can trust the component.
This brings us to the topic of Trust Management in component based software engineering.

Cross roads

For the past two or three years, I've been working on SOA (Services Oriented Architecture) systems. To be more specific web services. In the same time I was lucky enough to study/implement certain web services security specifications, by polishing my knowledge in Computer Security.
As I start my higher studies in Swinburne University of Technology, now I'm expanding my knowledge towards adaptive systems. I'm now hopping along this new axis with the help of Swinburne Research in Melbourne.
I'm still just enjoying the sceneries in this path and occasionally glance through the track I used to travel earlier.
Would I be able to divert the current path and form a new junction with the former?
Or is it too early sketch the map?

Seven things to know about FEDi

FEDi is
- about authentication and to enable single sign on in a federated environment
- to establish the trust between entities in different security realms
- based on Apache Axis2/C and Apache Rampart/C
- to provide the infrastructure to develop identity enabled web services
- is an effort to implement WS-Trust, SAML and WS-Federation specifications in C language


FEDi is NOT
- a product/application. It's a framework that can be used to implement the final product/application.
- an alternative to Identity Solution. It's an effort to extend the capabilities to federated environment

Need to know more check this out

Cardspace authenitcation with Identity Solution

WSO2 Identity solution 1.5 has been released. The new version supports SAML 2.0, which is a very handy feature to have.
Check more details about the release here.
You can also listen to this podcast by Prabath Siriwardena

Self signed certificates using OpenSSL

Use the following command to generate a self-signed x509 certificate (mycert.pem), which is valid for 365 days and an RSA key (mykey.pem) of length 1024.

openssl req -x509 -nodes -days 365 -newkey rsa:1024 \
-keyout mykey.pem -out mycert.pem

Then you have to answer few questions. The information you provide by answering these questions will be stored in the certificate.

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:

That's it !!!

Facing security threats with WSF/PHP

Following table shows how to use/combine WSO2 WSF/PHP security features to face the common web services security threats...



Note that it is necessary to use username tokens with transport level security

Apache Rampart/C 1.1.0 is released

Apache Ramaprt/C team has unleashed it's version 1.1.0 y'day.
Check the feature list here...
The project is to fulfill the message level security requirements of the Apache Axis2/C engine. Without worrying about having custom mechanisms to provide message confidentiality, integrity and authentication requirements, it is very easy to use the Rampart/C module with the Axis2/C engine.
The released version is compatible with the Apache Axis2/C 1.2.0.
You may download the latest version here...

WSO2's WSF/PHP and Apache Ramaprt/C

Following diagram shows how the WSO2 WSF/PHP is arranged...



Basically the WSO2 WSF/PHP is a PHP extension. It can be seen as the upper layer of a 3-core wire.
And inside it there is another layer wrapping many other products, which we call the WSO2 WSF/C. These products are the implementations of WS-* of specifications including Apache Rampart/C, Apache Sandesha2/C, Apache Savan/C.
A PHP user will basically consume/provide web services by using the upper WSF/PHP layer. The core specifications and implementations are transparent to the PHP user to make the life easier. But sometimes it's worth to know how exactly are the inner components arranged. :)

In order to provide security, WSO2 WSF/PHP uses Apache Rampart/C. Actually via WSO2 WSF/C. Apache Rampart/C is the security module for the Apache Axis2/C engine, which the WSF/PHP depends on. You may refer my this blog entryto see how to write a PHP script to encrypt a SOAP message.