Sunday, December 30, 2012

Installing StockLite v8 on Galaxy Ace

My Galaxy Ace started automatically going to "Emergency Calls Only" mode and I had to restart the phone in order to connect with the operator again. Since I couldn't find a solution for this, thought of installing a custom ROM and check.

I didn't want gimmicks; stability of the ROM was what important. So, while searching for such, I came across StockLite V8 [1]. The developers have removed many unwanted apps of the stock ROM resulting in increased internal phone memory and battery life. They have added many other cool things like screenshot option and rebooting options to the power button, various lock-screen themes, performance customizations  and etc. Reviews were good so I decided to give it a go.

1. Root the device [2]
2. Install ClockworkMod Recovery (CWM) V5 [3]
3. Install StockLite V8 [1]

Seems all good for now. Let's check how Ace copes with the ROM and whether that issue will come again :)

[1] StockLite v8 xda-dev thread
[2] How to Root the Ace
[3] How to install CWM Recovery on Ace

Additional Refs:
[4] Samsung Galaxy Ace: All Things Root Guide
[5] Universal Gingerbread Root & Unroot 2.3.3 -> 2.3.7+
[6] What Is ClockworkMod Recovery And How To Use It On Android [Complete Guide]
[7] Reverting to STOCK Recovery from CWM
[8] How to Unroot the Ace

Friday, December 28, 2012

Plain-text Passwords based Authentication change in WSS4J 1.6+

I was going through the tutorial in [1] using plain-text passwords for UsernameToken authentication via a policy. (A deprecated method for this type of authentication without a policy is explained in this post). In Axis2, WS-Security aspects are handled by Rampart module by using WSS4J as the provider. I used the version 1.6.4 of it, which comes bundled with Rampart 1.6.2.

Ideal mechanism of plain-text passwords based authentication is, when Rampart receives the request, it should handover the username and the password to the call back handler that user writes. This handler will use its specific authentication mechanism (or delegate to an authentication component/system) to compare this plain-text password with a stored password which will be most probably in an encrypted form. Simply, the responsibility of authentication should be user's.

However, things didn't work according to the tutorial; authentication started to fail.

Debugging WSS4J took me inside UsernameTokenValidator class, which didn't exist prior to 1.6. I found out that even though client sends the password in plain-text, by default WSS4J will do the validation the digest-password way. i.e verifyPlaintextPassword() in that class simply calls verifyDigestPassword(). So, it always sends a null value to the password callback handler and the user is supposed to provide a plain-text password to Rampart. This is not the ideal mechanism.

Then I found [2] where it explains that starting from WSS4J 1.6, UsernameToken processing architecture has been modified. By default it no longer handles the plain-text passwords the old way. Validations are not hard wired to UsernameTokenProcessor, which was the case prior to WSS4J 1.6. Validators such as UsernameTokenValidator - which is the default validator - should be custom written.

So, if we want the ideal behaviour we talked, we must write a custom validator, in which we should @Override verifyPlaintextPassword() with the implementation we prefer and plug that validator to the UsernameTokenProcessor instead of the default UsernameTokenValidator.

Rational behind this architectural change can be read in [2].


Thursday, December 27, 2012

How to add Eclipse shortcut to Ubuntu Dash

Create file /usr/share/applications/eclipse.desktop with the following info.
[Desktop Entry]
Comment=Eclipse IDE
Exec property indicates where Eclipse executable is located.
Icon indicates where to find the Eclipse icon that should be displayed in Dash.

Wednesday, December 19, 2012

How to add multiple jars to Java classpath in Linux using wildcards

Add following line to the .bashrc file in the user's home directory.
export CLASSPATH="/home/dulanja/dev/axis2-1.6.2/lib/*:$CLASSPATH"
However, it should be noted that wild-card (*) support is there only for Java6 and above. For previous Java versions, jars should be (tediously) individually added.


Tomcat gives an Internal Server error when trying to access Axis2 web services using HTTPS. What's missing?

It is assumed that HTTPS is enabled for Tomcat by defining a Connector with a key store in the server configuration (server.xml) file. What is not working is Axis2 in that server. When we try to access a service wsdl using the web browser the Internal Server Error message is displayed.

This happens due to axis2 configuration missing the HTTPS transport receiver. Following should be added to Axis2.xml in the Tomcat Axis2 web app.
<transportReceiver name="https"
        <parameter name="port">8443</parameter>

Monday, December 17, 2012

Key Stores and Trust Stores

The meaning of a Key Store is a database (usually in the form of a disk file) where private/public keys and certificates - which can be used for signing encrypting and creating trust - are stored.

However, for the sake of being clearer, two separate files are usually used...

One for storing private keys, certificates and their corresponding public keys, which is generally called the Key Store.

And another to store the certificates of trusted parties (these can include certificates from Certificate Authorities) and their public keys, which is called a Trust Store.

In Java the file extension for these stores goes as .jks. And access to both these file types are done using the KeyStore class.

Creating key stores can be done using the Java keytool command.


Sunday, December 16, 2012

SOAP Header's 'MustUnderstand' Attribute

This is an attribute that applies to SOAP headers.
<wsse:Security xmlns:wsse=""
If the value of it is "true" or 1, it tells the SOAP processor that processing should not continue if that header cannot be recognized. That it's a must to understand the header.

If fails to understand, an error should be returned and all the processing already done for that SOAP request should be rolledback.

If it is "false" or 0, even if the processor can't understand that particular header, rest of the message will be processed.


Friday, December 14, 2012

Remote Debugging Tomcat with Eclipse

Tomcat should be started with debug options. This can be simply done by adding the jpda option when running as follows.
./ jpda start
When jpda option is provided catalina will set some default debug related options such as the debug port (default is 8000) and etc. User can change these values in the script if a custom behaviour is needed.

Then in Eclipse we should create a new debug configuration (Run -> Debug Configurations... in Indigo). Under the 'Remote Java Application' located in the menu to the left of the configuration pop-up, we should create the new configuration giving the Host (location of the remote server, this can be localhost also) and the debug Port that we set while starting Tomcat (default 8000). Also, an Eclipse project can be given where the sources needed for debugging is located.

Then, when we press 'Debug' and go to the 'Debug Perspective', we'll be able to see the Tomcat application getting remote debugged.

We'll be able to set breakpoints in the source, inspect values and utilize all the usual facilities we get when debugging inside Eclipse.

How Digital Signatures Work

Similarly to handwritten signatures, digital signatures ensure the authenticity of a message.

Authenticity is concerned with 2 aspects:
  1. The message was sent by the actual sender (not an imposter).
  2. Message was not altered after sender sent it.
Usually, to achieve this, a hash value (which is also called a 'digest') will be computed using a hashing algorithm (e.g. SHA-1) and then this value will be encrypted using the senders private key (this talks about encryption). Resulting value will be sent along with the message.

When this message is received by the intended party, they will try to decrypt it with the senders public key (which was transmitted to the receiver beforehand). If the decryption is successful it indicates that the message was from the actual sender...not by an imposter!

Then the receiving party will calculate the hash value of the message using the same hashing algorithm used by the sender. If the computed value and the value sent encrypted by the private key is equal, it ensures that the message wasn't altered en route.


Thursday, December 13, 2012

How Encryption works

en = make | crypt = secret

Encryption is making something secret so unauthorized parties cannot read it.

Encryption algorithms are used to encrypt/decrypt the data, and a specific value named Key is used in these algorithms. This value is named as such because it's the key for locking and unlocking the encrypted data.

When encrypting, these algorithms take the data (in plain-text) and a key as the input and output the cypher-text (data in an unreadable format).

When decrypting, they take the cypher-text and a key as the input and output  plain-text data.

Encryption algorithms are publicly available and the only thing an unauthorized party requires to access the data is this key.

There are two key based encryption mechanisms...

1. Symmetric Encryption

Symmetric = both sides equals. 
So, Symmetric Encryption = encryption/decryption by the same key.

This is also called the shared key encryption. The key is known by both the originating and the intended receiving party, and it is used for both encryption and decryption.

Advantage : Fast
Disadvantage : Delivering shared key securely to the other party is no easy task.
    2. Asymmetric Encryption

    Asymmetric = two sides are not equal.
    So, Asymmetric Encryption = encryption done by one key...decryption by a different key.

    This is also called as Public Key Encryption. In this method a key pair is used. A Private Key and a Public Key. Private key is known only by you! Public key is given to the other party. If data is encrypted using the private key it can be decrypted only by the public key, and vice versa. Same key cannot do both.

    The public key will be distributed to the other communicating parties. If someone in-between plucks harm! Let's see why...

    When A wants to send data to B, A will encrypt it using the public key he  received from B. Remember, data encrypted by a public key cannot be decrypted by the same key. So even if an unauthorized person takes the data from the wire he cannot read it. It can be opened only by the private key of B! When B sends a response back, he will do the same...encrypt using the public key of A.

    Wait! What if A encrypts the data using his private key...anyone having the public key can read it right? Yes. It won't be secure, but it will guarantee the receiving party that the data was sent by middle-man messed with data. This is a digital signature.

    Advantage : It removes the secure key distribution problem.
    Disadvantage : Slower. Best suited for small sizes.

    In message exchanges, usually a combination of above two methods are used. The data itself is encrypted using symmetric encryption, and that shared key is then encrypted using asymmetric encryption.


    Tuesday, December 11, 2012

    Enabling UsernameToken Authentication with Axis2 without a Policy

    What is UsernameToken Authentication?

    This is a Web Service Security (WSS) specification published by OASIS that defines how two communicating parties can authenticate a message using a username and a password.

    How to enable it in Axis2?

    To enable any WSS standard Apache Rampart should be used with Axis2. To engage Rampart with a web service, first Rampart and Rahas modules should be in the server and client repositories, and then add the following to the Axis2 configuration files at the client (axis2.xml) and server (service.xml) sides.
        <module ref="rampart" />
    Engaging Rampart to Axis2 will not do any good untill we specify Rampart how to do its job, which is, instructing what sort of security should be provided.

    In this post we will only consider UsernameToken Authentication and there are two ways to send the password: as a digested password or as plain-text.

    UsernameToken Authentication with Digested Password

    To instruct Rampart to use digest mode following markup should be included in the client's Axis2 configuration file...
        <parameter name="OutflowSecurity">
                <items>UsernameToken Timestamp</items>
    ...and in the Service's configuration file...
        <parameter name="InflowSecurity">
            <items>UsernameToken Timestamp</items>
    PWCBHandler is a class that implements the interface. The client and the service should implement the handle() method of it. Retrival of the password for the sent username is done inside this method.

    When a request is sent with this configuration a "Security" tag will be added to SOAP message....
        <wsse:UsernameToken wsu:Id="UsernameToken-1">
    What we have done is sending the password as a digest, which is computed by  client as follows:

    digest == base64 encoded (SHA-1 hashed (password + nonce + timestamp))

    [nonce is just a random number]

    And then at the service side, Rampart will get the password for the particular username via the PWCBHandler from a local user store, and then do the digest computation using the nonce and timestamp sent by client. If the two digests evaluates to true, then message is authenticated.

    However, there's a weakness in this mechanism...

    Since Rampart does the computation of the digest using nonce and timestamp, a plain-text password should be supplied to it from the PWCBHandler. Handling plaintext passwords is a security vulnarebility.

    Solution for this is using the plain-text way...

    UsernameToken Authentication with Plain-text Password

    Adding an extra line to the client side configuration we did above will change the mechanism to plain-text passwords. Note the "passwordType" tag in the below markup...
    <parameter name="OutflowSecurity">
    The SOAP request with the plain-text password...
        <wsse:UsernameToken wsu:Id="UsernameToken-1">
    Here, handling the authentication will be done by the service. Rampart will simply handover the username and the password to the PWCBHandler, and handler will use its specific authentication mechanism (or delegate to an authentication component/system) to compare this plain-text password with a stored password which will be most probably in an encrypted form.

    UPDATE 26/12/12: UsernameToken Authentication is no longer used without policies. This blog post was written while playing with Rampart samples. Though this is still available in the latest Rampart dist's samples folder, it should not be used for production.


    Monday, December 10, 2012

    What is Axis2?

    Axis2 is an open-source framework by Apache Software Foundation to ease the handling of web service requests and responses. Both SOAP and REST type communications are supported by this.

    Why is it needed?

    If not for such a framework, web service (and service consumer) developers would have to handle tedious operations like message transportation, security and XML parsing, which consume lot of time that can be best utilized for business logic writing.

    Also, handling those operations could turn out to be highly error-prone. So, a framework like Axis2 provides tested re-usability and removes the burden from the developers.

    How does Axis2 work?

    A quick overview...

    Axis2 is an extensible framework which consists of number of built-in as well as  customizable modules that can be plugged-in to add specific functionality.

    Each module introduces a set of handlers, which do the actual operations/processing.

    In each module, the configuration file (module.xml) specifies a phase in which these handlers will be executed. These phases are defined in the axis2's main configuration file (axis2.xml) and they are assigned to two message flows: In Flow (called In Pipe) and Out Flow (Out Pipe).

    Handlers defined for In Flow gets executed when a message is received from Axis2 and handlers for Out Flow are executed when a response is sent.


    Apart from this architectural overview, it should be noted that Axis2 uses its own object model - AXIOM (Axis Object Model), and StAX (Streaming API for XML) for XML parsing.

    Some in-depth workings of Axis2 will be discussed in future posts.