Soft hands with heavy weapons - stories of LTTE child soldiers

A new set of books on LTTE child soldiers are to be released soon, hopefully late September.

These unveil just a bit of brutality and cruelty the LTTE released on generations over the past.

Kids were given weapons and forced from play-ground to the battle field.

They lost their parents, brothers and sisters - what else, LTTE killed their childhood in the name of so called 'Liberty' of Tamil people.

All the child soldiers in these stories unveil the truth. They cried and cursed LTTE.

Parents listening to their stories will neither join nor support Tigers.

LTTE is not an organization to bring Liberty to Sri Lankan Tamils, but a group of heartless people who always brought tears in to innocent Tamils.

They exploited the innocence in Tamil kids to inseminate the seeds of anger.

They mislead the courage in Tamil youth to fire bullets against Buddhist priests.

The author of these books spent nights in North & Eastern province, areas - under SLA control, meeting LTTE child soldiers.

Books will be translated in to both English and Tamil.

Creating a new JKS with an existing private key and a signed certificate

You have your own private key and a CA signed certificate - and now you want to import both the key and the certificate to a new JKS.

This is how we do it and you need to have OpenSSL installed.

For Windows you can download Win32 OpenSSL v0.9.8g from here.Once installed make sure you add C:\OpenSSL\bin [i.e [INSTALLED_LOCATION]\bin] to the PATH env variable.

If your key and certificate are in PEM format, then you need to convert them into DER format. [privateKey.pem & signedCert.pem]

:\> openssl pkcs8 -topk8 -nocrypt -in privateKey.pem -inform PEM -out privateKey.der -outform DER

:\>openssl x509 -in signedCert.pem -inform PEM -out signedCert.der -outform DER

Copy the resulted signedCert.der and privateKey.der to c:\keys.

Java keytool does not support a direct way of importing an existing private key to a new key store. So, we'll be doing it programmatically.

You can download the code from here and copy it to c:\keys.

c:\keys\>javac BuildJKS.java

c:\keys\>java BuildJKS privateKey.der signedCert.der mykeyalias MyJKS.jks keypassword storepassword

The above will create a JKS with the name MyJKS.jks and the key store password will be storepassword while the private key password is keypassword. Also the alias of the imported key is mykeyalias.

To verify that the JKS being created properly just issue the following command to list certificates stored in the key store.

c:\keys\>keytool -list -keystore MyJKS.jks -storepass storepassword

Detecting Information Card Support

Following javascript will help you to detect Information Card support of a given browser and display Information Card based logins accordingly.

function isSupported()
{

  var ieversion = -1;

  if (navigator.appName == 'Microsoft Internet Explorer' ) {

    if (new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})").exec(navigator.userAgent) != null) {

      ieversion = parseFloat(regExp.$1);

      if (ieversion >= 7) {

        var embed = document.createElement("object");
        embed.setAttribute("type","application/x-informationCard");
        return ("" + embed.issuerPolicy != "undefined" && embed.isInstalled);

      }

      if (ieversion < 0 && navigator.mimeTypes && navigator.mimeTypes.length) {

        var handler = navigator.mimeTypes['application/x-informationCard'];

        if (handler && handler.enabledPlugin)
        return true;

        if (document.addEventListener) {

          var event = document.createEvent("Events");
          event.initEvent("IdentitySelectorAvailable",true,true);
          top.dispatchEvent(event);

          if (top.IdentitySelectorAvailable == true) return true;

        }

      }

    return false;

    }

  }

}

Information card support for IE 7+ is added using a browser add-on. To test the above sacript with IE 7+, you can simply enable/disable it as shown below.

Personal Information Cards Under the Hood

Personal Information Cards provide a way where you can use them to register yourself with a web site and further use it to authenticate yourself.

This eliminates the burden of typing all your personal information each and every time you register with a new web site.

Once you have a personal information cards with the required claim values, the same card can be used at different websites for the purpose of registration and authentication.

This raises a question...

How come a given web site identifies you as a unique idenity based on your information card ?

Each and every information card has a non-editable claim value - known as Private Personal Identifier [PPID]. This is generated by the CardSpace it self.

For each personal information card you create, CardSpace generates a master key and a Card ID. Master key is 32 bytes of random data and Card ID is a GUID. This makes each card created unique from the rest of the cards.

PPID is not just unique for the information card it self.

It is a unique value for the Information Card + Relying Party combination.

PPID is generated with the CardID and with some properties from the RP certificate.

In case RP does not have a certificate, then it's the domain name from the site url is used along with the Card ID.

Apart from the PPID, CardSpace also creates a public/private key pair for the personal information card.

CardSapce uses the master key of the card along with some properties from the RP certificae to generate this public/private key pair.

Relying Party can retrieve the public key and the PPID from the Information card submitted to it and the user information can be stored against the PPID.

All the information sent with the card will be signed by the private key corresponding to that card.

So, once an RP gets a Card for authentication - it can verify the uniqueness of the user with the PPID and check the integrity with the public key.

The PPID generated by the CardSpace is a Base64 encoded SHA1 hash. This looks something like;

2QLepiNor3AfYCJ2tN9m3IlNXKNA/iwpVV+FCU1ZhxQ=

That is never readable and to avoid that there is a way you can generate a much readable site-specific id from it.

Mooshup: The yougest member of the OpenID family

WSO2 Mashup team recently upgraded their community site, Mooshup, with the Mashup Server 1.5.1.

With this, Mooshup enbles OpenID login - in addition to the Information Card based login, which it had already supported.

Randall says, the OpenID initiative, a 'waste of energy'.

Randall Stross in his recent article to The New York Times, highlights some of the very valid issues against the use of passwords.

"I once felt ashamed about failing to follow best practices for password selection — but no more. Computer security experts say that choosing hard-to-guess passwords ultimately brings little security protection. Passwords won’t keep us safe from identity theft, no matter how clever we are in choosing them."

Best practices on selecting better passwords always only provide guidelines for how to select a password which is 'hard to guess' - NOT unbreakable. With this point, I totally agree with Randall - Yes, true - passwords do not seem to be the 'right' solution for digital identity.

He further adds.

"As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code."

Yes, true - information cards provide a cryptographic solution to the authentication problem in a phishing resistant manner.

Even in this case - passwords are not totally taken out of the picture.

A given information card can be backed by a username/password, a self-issued information card or an X.509 token.

Also, in all three cases - if your machine, where you have installed all your Information cards, is protected by username/password - still we have not totally eliminated the risk of using passwords. Anybody who steals your machine username/password can easily use any of your information cards to authenticate in to any of the relying party web sites who accept your information cards.

Here comes the most interesting part of Randall's article.

"We won’t make much progress on information cards in the near future, however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative. OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials."

Oops... I am sorry... I totally disagree.

First I disagree with him on the point about Information cards.

CardSpace has made a good progress in the past and it will definitely in the future. It's not just Microsoft that has taken the CardSpace initiative forward - but it has also attracted many open source vendors as well. For example, WSO2 with it's Identity Solution has support for CardSpace - both as an Identity Provider as well as providing relying party components.

Second - I totally disagree with him on his comments on OpenID.

"...however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative."

When such a comment is made - there needs to be enough facts to elaborate more on it. But, unfortunately there is nothing in it to justify.

Both OpenID and CardSpace are two technologies which support user-centric identity.

When you say - 'OpenID vs CardSpace' - it's simply an invalid statement. It should be 'OpenID and CardSpace'. Both the technologies work together smoothly. Please read this blog post by Kim Cameron.

"...OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site."

This is totally misleading.

OpenID specifications never promote a single way of authenticating users to the OpenID Provider.

It can be username/password ,X.509 certificates or even Information cards.

I can take out many examples from the the web which support many of these authentication mechanisms for user authentication.

Randall, further adds.

"...Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised."

Once again - it seems Randall has misunderstood OpenID as a way of password-based login - sorry, sir - it is not.

Identity Governance Framework

This post summarizes the white paper 'Identity Governance Framework' by Oracle.

IGF initiative was first announced in November 2006 by Oracle and in November 2007 it was submitted to Liberty Alliance.

Identity Governance Framework (IGF) helps enterprises easily determine and control how identity related information, including Personally Identifiable Information (PII), access entitlements, attributes, etc. are used, stored (in multiple sources), and propagated between their systems.

It enables organizations to define enterprise level policies to securely and confidently share sensitive personal information between applications that need such data, without having to compromise on business agility or efficiency.

In other words IGF allows to define a set of business rules around usage of identity-related data.

For example user's SSN should only be used in an application that works on behalf of the user - where in all the other cases no application should have access to that specific piece of data.

Further,IGF focuses on following attributes:

- Decouple applications from deployment infrastructure
- Include identity-related data stored inside and outside classic enterprise directory
- Access to user attributes and entitlement data
- Policy-driven to support management and governance

In other words, IGF defines a set of declarative contracts between suppliers and consumers of identity-related information based on two standards - CARML and APPML.

The Identity Governance Framework (IGF) is designed to allow:

1. Application developers to build applications that access identity-related data from a wide range of sources
2. Administrators and deployers to define, enforce, and audit policies concerning the use of identity-related data.

IGF has four components:

1. Identity attribute service - a service that supports access to many different identity sources and enforces administrative policy
2. CARML: declarative syntax using which clients may specify their attribute requirements
3. AAPML: declarative syntax which enables providers of identity-related data to express policy on the usage of information,
4. Multi-language API (Java, .NET, Perl) for reading and writing identity-related attributes.

Client Attributes Requirements Markup Language (CARML) is a specification built by the developer during the development process (much like WSDL is to a web service).

In other words CARML is targeted towards the developers who develop applications which consume identity-related data.

This specification indicates the required and optional attributes, operations, and indexes the application will use when deployed.

Attribute Authority Policy Markup Language (AAPML) is a contract between an attribute authority and an attribute service.

AAPML is targeted towards the identity providers and defines the constraints under which identity data is released.

In other words, it specifies the rules and constraints to access attributes brokered by the service.

These rules are expressed using a form of XACML specifically focused on attributes, based on XACML 2.0.

For example, following rules/obligations will be considered by the identity provider to release identity-related data.

- Subject – characteristics of application, user, strength of authentication
- Resources – attribute names
- Actions – read or write
- Environment – Internet/Intranet/VPN/..
- Consent – availability of specific consent records
- Relationship between Subject and requested identity information
- Whether data can be cached or propagated further

The developer builds their application with minimal or no regard for how or where identity-related data comes from or is stored.

The application developer uses the CARML API to both declare the attribute data needed for the application and the operations needed to support the application.

The declaration is then used to either extract a CARML XML document (for manual configuration), or is automatically asserted when the application connects to the attribute service.

As far as the application developer is concerned, the attribute service manages how and where all identity-related data is processed.

The attribute authority works with attribute service administrator to decide under what conditions specific data may be released.

Together, they work together to define an AAPML document which specifies how and when the attribute services provide access to the authorities information and what operations are enabled.

Attribute service administrators take CARML requirements from applications and reconcile those requirements with available attribute data and existing policies.

They may be required to define mappings to handle differences between client applications and attribute sources.

For example, a client application might have an attribute SsnLast4Digits. While this doesn’t exist in any data store, they could create a mapping that simply allows matching against the last four digits of SSN in an appropriate attribute authority.

This allows for both schema conversion and enhancing usage of minimal information.

With IGF, enterprises will benefit in following ways:

- Rapid deployment of applications without change to identity infrastructures
- Meet legal, regulatory and enterprise policies on managing identity data

Never they leave... just checking out...

Dr. Sanjiva, addressing the farewell party to Ruchith,Deepal,Saminda, Sanka, Sandakith, Dinesh, Diluka, Suran & Chandima - who left the company for higher studies, mentioned, "You can check-out WSO2 any time you like, But you can never leave!" - following the famous Hotel California.

I've been working closely with Ruchith during last year or so - in fact Ruchith is the one who interviewed me for WSO2.

To be honest, it's my privilege to work with such a talented person.

He's not just technically talented - but a great presenter, a patient teacher and a fantastic leader.

Ruchith has made him self famous in the open source community - specially in the web services security arena - and the WSO2 Identity Solution is a brain child of him - but he still finds time to answer any dumb question thrown to him.

I am still young to WSO2 to admire his service there - but any WSO2er will.



I recently had an opportunity to go on a business trip to UK/US with Ruchith and while we were in US we visited one of our clients there and on the way back to hotel - Ruchith mentioned that he truly feels guilty to leave WSO2 at this moment. He further added that - WSO2 has built him up during last few years from zero to hero - and at the time he's in a great shape to help back WSO2 - he has to leave - which he felt guilty about.

Also, once we were in London, due to extremely personal reasons - Ruchith had to say 'no' to a request came to him from the company to do a training on Axis2. It was a very valid reason - and he had no other option. Later, from my colleagues at WSO2, I learnt that this was the first time Ruchith has said 'no' for such a request - it was clearly reflected on his face just after conveying his decision back to the company - and I have never seen Ruchith being so upset, before.

Once again, I am still young to WSO2 to comment on his loyalty - but, any WSO2er will.

That is... just one side of the story - let me add few words on the other side as well.

There was a time Ruchith felt he should postpone his admission to grad school by either a semester or by an year.

Any company CEO will definitely admire this decision and probably put a party on this.

But, Dr.Sanjiva, knowing very well the value Ruchith can add to WSO2 - encouraged him to leave the company to pursue his higher studies on time - which Ruchith finally had to agree.

This is fantastic - but not a surprise to anybody aware of WSO2 culture.

Ruchith: it's been great working with you for last few months and I wish you all the very best for all your higher studies - make your country and people proud of you...!!!

Autopost to Everywhere

Only thing worries me here is, I have to give my username/password of all the other services I need to work with posterous to posterous :(

Complex Event Processing with Esper and WSO2 ESB

view presentation (tags: esbwso2esper)