F a c i l e L o g i n

#Numbers 2011

2011-12-22T19:43:00.025+05:30

Population

World Population by end of 2011 is 7 Billion.
Population in China is 1.3 Billion.
Population in India is 1.19 Billion.

Facebook

800 Million users by the end of 2011.
Expenses, 1 Billion US $ per year.
3000 employees.
10% of people have less than 10 friends, 20% have less than 25 friends, while 50% have over 100 friends.
Facebook's Datawarehousing Hadoop cluster gets 12 TB of compressed data per day, 800 TB of compressed data scanned per day, 25,000 map-reduce jobs per day, 65 millions files in HDFS and 30,000 simultaneous clients to the HDFS NameNode
Stores over 320 billion images, which translates to over 25 petabytes of data
Users upload one billion new photos (~60 terabytes) each week
In June 2011, Facebook hit one trillion page views that month, with 870 million unique visitors for the same period, giving the site a staggering 46.9% reach among all web surfers.

Microsoft

330 Million Hotmail users.
90,000 employees.
Bought Skype for $8.5 Billion.
In June 2011, Microsoft hit with 250 million unique visitors, giving the site a 14.5% reach among all web surfers.
In June 2011, MSN hit with 440 million unique visitors, giving the site a 25.8% reach among all web surfers.

Google

260 Million GMail users.
62 Million Google+ users.
31,000 employees.
Britney Spears has the highest number of followers in Google+ with 1,096,945 followers while Larry Page is the second.
In June 2011, YouTube hit with 800 million unique visitors, giving the site a 46.8% reach among all web surfers.
In June 2011, Blogspot hit with 340 million unique visitors, giving the site a 19.6% reach among all web surfers.

Twitter

250 Million Tweets per day.
100 Million users.
400 employees.
In June 2011, Twitter hit with 160 million unique visitors, giving the site a 9.3% reach among all web surfers.

Yahoo

302 Million users.
14,000 employees.
42,000 nodes in the Hadoop cluster.
Flickr stores more than 5 Billion photos.
Flickr gets 100,000 queries per second.
In June 2011, Yahoo hit with 590 million unique visitors, giving the site a 34.4% reach among all web surfers.

Apple

61,000 employees.
500,000+ apps available in Apple App Store
18,000,000,000 downloads from the Apple App Store
iTunes Store had 225 million active users by June 2011

WSO2 Secuity Team - all back in Colombo office to celebrate Christmas

2011-12-21T02:37:00.006+05:30

2011 was a very busy year for WSO2 and specially for the Security team. We have 6 members in the team and it was hardly found a day all six were in Colombo WSO2 office...

Thilina was in Denmark in March for a customer engagement. In May he was in Switzerland and in July Thilina was in Denver for Cloud Identity conference. In November he was in Sweeden for another customer engagement.

Amila was in California from February to April. And back in US, in Raleigh, NC in September for a customer engagement. In October he was in New York for another customer engagement.

Asela was out during March/April for a customer engagement in North Carolina. In July Asela was in Denver for Cloud Identity conference and in New York once again for a customer engagement. In August he was at WSO2 Palo Alto office and did the Could Security workshop there with Asanka and me. Again in November he left to San Diego for a customer engagement. Just after one week he returned back to SL - he left to Germany for another customer engagement.

Hasini was out of the country in June - for a customer engagement in Indianapolis.

Manjula was in Thailiand in November to present WSO2 Identity Server at APICTA. And he left to Germany soon after that for a customer engagement - which finished in December.

I was in New York, Washington & Dallas in March for the WSO2 SOA Security & Identity Workshops and in July was in Denver for Cloud Identity conference and in New York once again for a customer engagement. In August I was at WSO2 Palo Alto office and did the Could Security workshop there with Asanka and Asela. Once again I was back in New York in October for another customer engagement and also for a workshop on Cloud Security. In November I was in Vancouver - Canada for the ApacheCon.

It's great to see the entire team is back in Colombo, by the end of the year...

2-legged OAuth with OAuth 1.0 and 2.0

2011-12-20T14:14:00.020+05:30

OAuth 1.0 emerged from the large social providers like Facebook, Yahoo!, AOL, and Google. Each had developed its own alternative to the password anti-pattern. OAuth 1.0 reflected their agreement on a single community standard.

In 2009, an attack on OAuth 1.0 was identified which relied on an attacker initiating the OAuth authorization sequence, and then convincing a victim to finish the sequence – a result of which would be the attacker’s account at an (honest) client being assigned permissions to the victim’s resources at an (honest) RS.

OAuth 1.0a was the revised specification version that mitigated the attack.

In 2009, recognizing the value of more formalized standardization, that community contributed OAuth 1.0 to the IETF. It was within the IETF Working Group that the original OAuth 1.0 was reworked and clarified to become the Informative RFC 5849.

In 2010, Microsoft, Yahoo!, and Google created the Web Resource Authentication Protocol (WRAP), which was soon submitted into the IETF WG as input for OAuth 2.0. WRAP proposed significant reworking of the OAuth 1.0a model.

Among the changes were the deprecation of message signatures in favor of SSL, and a formal separation between the roles of ‘token issuance’ and ‘token reliance.’

Development of OAuth 2.0 in the IETF consequently reflects the input of both OAuth 1.0, OAuth 1.0a, and the WRAP proposal. It is fair to say that the very different assumptions about what are appropriate security protections between OAuth 1.0a and WRAP have created tensions within the IETG OAuth WG.

While OAuth 2.0 initially reflected more of the WRAP input, lately (i.e. fall 2010) there has been a swing in group consensus that the signatures of OAuth 1.0a that were deprecated by WRAP are appropriate and desirable in some situations. Consequently, signatures are to be added back as an optional security mechanism.

While many deployments of OAuth 1.0a survive, more and more OAuth 2.0 deployments are appearing – necessarily against a non-final version of the spec. For instance, Facebook, Salesforce, and Microsoft Azure ACS all use draft 10 of OAuth 2.0.

[The above paragraphs are direct extracts from the white-paper published by Ping Identity on OAuth]

OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.

In the traditional client-server authentication model, the client requests an access restricted resource (protected resource) on the server by authenticating with the server using the resource owner's credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third-party. This creates several problems and limitations.

1. Third-party applications are required to store the resource owner's credentials for future use, typically a password in clear-text.

2. Servers are required to support password authentication, despite the security weaknesses created by passwords.

3. Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.

4. Resource owners cannot revoke access to an individual third-party without revoking access to all third-parties, and must do so by changing their password.

5. Compromise of any third-party application results in compromise of the end-user's password and all of the data protected by that password.

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner.

The protocol centers on a three-legged scenario, delegating User access to a Consumer for resources held by a Service Provider. In many cases, a two-legged scenario is needed, in which the Consumer is acting on behalf of itself, without a direct or any User involvement.

OAuth was created to solve the problem of sharing two-legged credentials in three-legged situations. However, within the OAuth context, Consumers might still need to communicate with the Service Provider using requests that are Consumer-specific. Since the Consumers already established a Consumer Key and Consumer Secret, there is value in being able to use them for requests where the Consumer identity is being verified.

This specification defines how 2-legged OAuth works with OAuth 1.0. But it never became an IETF RFC.

With OAuth 1.0 - 2-legged OAuth includes two parties. The consumer and the service provider. Basically in this case consumer also becomes the resource owner. Consumer first needs to register a consumer_key and consumer_secret with the service provider. To access a Protected Resource, the Consumer sends an HTTP(S) request to the Service Provider's resource endpoint URI. The request MUST be signed as defined in OAuth Core 1.0 section 9 with an empty Token Secret.

All the requests to the Protected Resources MUST be signed by the Consumer and verified by the Service Provider. The purpose of signing requests is to prevent unauthorized parties from using the Consumer Key when making Protected Resources requests. The signature process encodes the Consumer Secret into a verifiable value which is included with the request.

OAuth does not mandate a particular signature method, as each implementation can have its own unique requirements. The protocol defines three signature methods: HMAC-SHA1, RSA-SHA1, and PLAINTEXT, but Service Providers are free to implement and document their own methods.

The Consumer declares a signature method in the oauth_signature_method parameter, generates a signature, and stores it in the oauth_signature parameter. The Service Provider verifies the signature as specified in each method. When verifying a Consumer signature, the Service Provider SHOULD check the request nonce to ensure it has not been used in a previous Consumer request.

The signature process MUST NOT change the request parameter names or values, with the exception of the oauth_signature parameter.

2-legged OAuth with OAuth 1.0 - the request to the protected resource will look like following.

http://provider.example.net/profile
            Authorization: OAuth realm="http://provider.example.net/",
            oauth_consumer_key="dpf43f3p2l4k3l03",
            oauth_signature_method="HMAC-SHA1",
            oauth_signature="IxyYZfG2BaKh8JyEGuHCOin%2F4bA%3D",
            oauth_timestamp="1191242096",
            oauth_token="",
            oauth_nonce="kllo9940pd9333jh",
            oauth_version="1.0"

This blog post explains with an example, how to use 2-legged OAuth with OAuth 1.0 to secure RESTful service.

Now, let's look at OAuth 2.0 - still at the stage of a draft specification. This doesn't talk about 2-legged OAuth. But - it can be implemented with different approaches suggested in OAuth 2.0.

Have a look at this & this - both talk about how to implement 2-legged OAuth with OAuth 2.0 - and those discussions are from the OAuth 2.0 IETF work group.

OAuth 2.0 defines four roles:

1. resource owner : An entity capable of granting access to a protected resource (e.g. end-user).

2. resource server : The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

3. client : An application making protected resource requests on behalf of the resource owner and with its authorization.

4. authorization server : The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

In case of 2-legged OAuth, client becomes the resource owner.

We can at very high-level break the full OAuth flow in to two parts.

1. Get a token from the authorization server
2. Use the token to access the resource server

Let's see how the above two steps work under 2-legged OAuth.

OAuth 2.0 defines a concept called - "authorization grant" - which is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types.

1. authorization code
2. implicit
3. resource owner password credentials
4. client credentials

"Client Credentials" is the grant type which goes closely with 2-legged OAuth.

With "Client Credentials" grant type, the client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control.

Once the client makes this request to the authorization server - it will return back an access token to access the protected resource.

The access token returned back to the client could be either of type bearer of MAC.

The "mac" token type defined in ietf-oauth-v2-http-mac is utilized by issuing a MAC key together with the access token which is used to sign certain components of the HTTP requests by the client when accessing the protected resource.

The MAC scheme requires the establishment of a shared symmetric key between the client and the server. This is often accomplished through a manual process such as client registration.

The OAuth 2.0 specification offers two methods for issuing a set of MAC credentials to the client using..

1. OAuth 2.0 in the form of a MAC-type access token, using any supported OAuth grant type. [This is what we discussed above - an access token with 'MAC' type]

2. The HTTP "Set-Cookie" response header field via an extension attribute.

When using MAC type access tokens with 2-legged OAuth - the request to the protected resource will look like following.

GET /resource/1?b=1&a=2 HTTP/1.1
     Host: example.com
     Authorization: MAC id="h480djs93hd8",
                        nonce="264095:dj83hs9s",
                        mac="SLDJd4mg43cjQfElUs3Qub4L6xE="

Bearer type is defined here. It's a security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

When using Bearer type access tokens with 2-legged OAuth - the request to the protected resource will look like following.

GET /resource HTTP/1.1
   Host: server.example.com
   Authorization: Bearer vF9dft4qmT

Also - the issued access token from the Authorization Server to the client, has an 'scope' attribute. [2-legged OAuth with OAuth 1.O doesn't have this scope attribute as well as access token concept - so resource server has to perform authorization separately based on the resource client going to access]

The client should request access tokens with the minimal scope and lifetime necessary. The authorization server will take the client identity into account when choosing how to honor the requested scope and lifetime, and may issue an access token with a less rights than requested.

When securing APIs with OAuth - this 'scope' attribute can be bound to different APIs. So, the authorization server can decide whether to let the client access this API or not.

The first Kolamba DZone Community Meetup

2011-12-16T11:20:00.005+05:30

We successfully completed the first Kolamba DZone meetup with 5O+ attendees from WSO2, University of Moratuwa, University of Colombo, Informatics and IFS.

We started the event by introducing DZone - since some guys were new to it..

Then we had a very interesting panel discussion on Big Data - which was followed by a demo.. and we ended up with some music.. and some 'nice' food.. Hope everyone enjoyed..

Thanks a lot WSO2 for sponsoring this event.. and thanks DZone for helping us to make this event a success..

Also thanks Srinath, Tharindu, Senaka, Wathsala, Deep, Shankar, Anjana and Buddhika for taking part in the panel discussion..

Thank you very much Pradeeban, Udedhika, Flora for your help in different aspects...

Thanks Charitha, Dassa, Chamara, ChamaraA for the wonderful performance at the end of the event...

At last , not least thanks a lot Harindu for owning everything and making everything perfect..

A SMALL cross-section of BIG Data

2011-12-15T01:37:00.022+05:30

Big data is a term applied to data sets whose size is beyond the ability of commonly used software tools to capture, manage, and process the data within a tolerable elapsed time. Big data sizes are a constantly moving target currently ranging from a few dozen terabytes to many petabytes of data in a single data set.

IDC estimated the digital universe to be around 1.8 zettabytes by 2011.

How big is a zettabyte? It's one billion terabytes. The current world population is 7 billion - that is, if you give a hard disk of 250 billion GB for each person on the earth - still that storage won't be sufficient.

Many sources contribute to this flood of data...

1. The New York Stock Exchange generates about one terabyte of new trade data per day.
2. Facebook hosts approximately 10 billion photos taking up one petabytes of storage.
3. Ancestry.com, the genealogy site, store around 2.5 petabytes of data.
4. The Internet Archive stores around 2 petabytes of data, and is growing at a rate of 20 terabytes per month.
5. The Large Harden Collider near Geneva will produce about 15 petabytes of data per year.
6. Everyday people create the equivalent of 2.5 trillion bytes of data from sensors, mobile devices, online transactions & social networks.

Facebook, Yahoo! and Google found themselves collecting data on an unprecedented scale. They were the first massive companies collecting tons of data from millions of users.

They quickly overwhelmed traditional data systems and techniques like Oracle and MySql. Even the best, most expensive vendors using the biggest hardware could barely keep up and certainly couldn’t give them tools to powerfully analyze their influx of data.

In the early 2000’s they developed new techniques like MapReduce, BigTable and Google File System to handle their big data. Initially these techniques were held proprietary. But they realized making the concepts public, while keeping the implementations hidden, will benefit them - since more people will contribute to those and the graduates they hire will have a good understanding prior to joining.

Around 2004/2005 Facebook, Yahoo! and Google started sharing research papers describing their big data technologies.

In 2004 Google published the research paper "MapReduce: Simplified Data Processing on Large Clusters".

MapReduce is a programming model and an associated implementation for processing and generating large data sets. Users specify a map function that processes a key/value pair to generate a set of intermediate key/value pairs, and a reduce function that merges all intermediate values associated with the same intermediate key. Many real world tasks are expressible in this model, as shown in this paper.

Programs written in this functional style are automatically parallelized and executed on a large cluster of commodity machines. The run-time system takes care of the details of partitioning the input data, scheduling the program's execution across a set of machines, handling machine failures, and managing the required inter-machine communication. This allows programmers without any experience with parallel and distributed systems to easily utilize the resources of a large distributed system. Google's implementation of MapReduce runs on a large cluster of commodity machines and is highly scalable.

A typical MapReduce computation processes many terabytes of data on thousands of machines. Programmers and the system easy to use. Hundreds of MapReduce programs have been implemented and upwards of one thousand MapReduce jobs are executed on Google's clusters every day.

Doug Cutting who worked for Nutch, an open-source search technology project which are now managed through the Apache Software Foundation, read this paper published by Google and also another paper published by Google on Google's distributed file system [GFS]. He figured out GFS will solve their storage needs and MapReduce will solve the scaling issues they encountered with Nutch and implemented MapReduce and GFS. They named the GFS implementation for Nutch as the Nutch Distributed Filesystem [NDFS].

NDFS and the MapReduce implementation in Nutch were applicable beyond the realm of search, and in February 2006 they moved out of Nutch to form an independent sub project of Lucene called Hadoop and NDFS, became HDFS [Hadoop Distributed File System] - which is an implementation of GFS. During the same time Yahoo! extended their support for Hadoop and hired Doug Cutting.

At a very high-level, this is how HDFS works. Say we have a 300 MB file. [Hadoop also does really well with files of petabytes and terabytes.] The first thing HDFS is going to do is to split this up in to blocks. The default block size on HDFS right now is 128 MB. Once split-ed in to blocks we will have two blocks of 128 MB and another of 44 MB. Now HDFS will make 'n' number of ['n' is configurable - say 'n' is three] copies/replicas of each of these blocks. HDFS will now store these replicas in different DataNodes of the HDFS cluster. We also have a single NameNode, which keeps track of replicas and the DataNodes. NameNode knows where a given replica resides - whenever it detects a given replica is corrupted [DataNode keeps on running checksums on replicas] or the corresponding HDFS node is dowm, it will find out where else that replica is in the cluster and tells other nodes do 'n'X replication of that replica. The NameNode is a single point of failure - and two avoid that we can have secondary NameNode which in sync with the primary -and when primary is down - the secondary can take control. Hadoop project is currently working on implementing distributed NameNodes.

Again in 2006 Google published another paper on "Bigtable: A Distributed Storage System for Structured Data"

Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size, petabytes of data across thousands of commodity servers. Many projects at Google store data in Bigtable, including web indexing, Google Earth, and Google Finance. These applications place very different demands on Bigtable, both in terms of data size (from URLs to web pages to satellite imagery) and latency requirements (from backend bulk processing to real-time data serving). Despite these varied demands, Bigtable has successfully provided a flexible, high-performance solution for all of these Google products. This paper describes the simple data model provided by Bigtable, which gives clients dynamic control over data layout and format, and describes the design and implementation of Bigtable.

BigTable maps two arbitrary string values (row key and column key) and timestamp (hence three dimensional mapping) into an associated arbitrary byte array. It is not a relational database and can be better defined as a sparse, distributed multi-dimensional sorted map.

Basically BigTable discussed how to build a distributed data store on top of GFS.

HBase by Hadoop is an implementation of BigTable. HBase is a distributed, column oriented database which is using HDFS for it's underlying storage and supports both batch-style computation using MapReduce and point queries.

Amazon, published a research paper in 2007 on "Dynamo: Amazon’s Highly Available Key-value Store".

Dynamo, is a highly available key-value storage system that some of Amazon’s core services use to provide an “always-on” experience. Apache Cassandra — brings together Dynamo's fully distributed design and BigTable's data model and written in Java - open sourced by Facebook in 2008. It is a NoSQL solution that was initially developed by Facebook and powered their Inbox Search feature until late 2010. In fact much of the initial development work on Cassandra was performed by two Dynamo engineers recruited to Facebook from Amazon. However, Facebook abandoned Cassandra in late 2010 when they built Facebook Messaging platform on HBase.

Also, besides using the way of modeling of BigTable, it has properties like eventual consistency, the Gossip protocol, a master-master way of serving the read and write requests that are inspired by Amazon's Dynamo. One of the important properties, the Eventual consistency - means that given a sufficiently long period of time over which no changes are sent, all updates can be expected to propagate eventually through the system and all the replicas will be consistent.

I used the term 'NoSQL' when talking about Cassandra. NoSQL (sometimes expanded to "not only SQL") is a broad class of database management systems that differ from the classic model of the relational database management system (RDBMS) in some significant ways. These data stores may not require fixed table schemas, usually avoid join operations, and typically scale horizontally.

The name "NoSQL" was in fact first used by Carlo Strozzi in 1998 as the name of file-based database he was developing. Ironically it's relational database just one without a SQL interface. The term re-surfaced in 2009 when Eric Evans used it to name the current surge in non-relational databases.

There are four categories of NoSQL databases.

1. Key-value stores : This is based on Amazon's Dynamo paper.
2. ColumnFamily / BigTable clones : Examples are HBase, Cassandra
3. Document Databases : Examples are CouchDB, MongoDB
4. Graph Database : Examples are AllegroGrapgh, Neo4j

As per Marin Dimitrov, following are the use cases for NoSQL databases - in other words following are the cases where relational databases do not perform well.

1. Massive Data Volumes
2. Extreme Query Volume
3. Schema Evolution

With NoSQL, we get the advantages like, Massive Scalability, High Availability, Lower Cost (than competitive solutions at that scale), Predictable elasticity and Schema flexibility.

For application programmers the major difference between relational databases and the Cassandra is it's data model - which is based on BigTable. The Cassandra data model is designed for distributed data on a very large scale. It trades ACID-compliant data practices for important advantages in performance, availability, and operational manageability.

If you want to compare Cassandra with HBase, then this is a good one. Another HBase vs Cassandra debate is here.

References :

[1]: MapReduce: Simplified Data Processing on Large Clusters
[2]: Bigtable: A Distributed Storage System for Structured Data
[3]: Dynamo: Amazon’s Highly Available Key-value Store
[4]: The Hadoop Distributed File System
[5]: ZooKeeper: Wait-free coordination for Internet-scale systems
[6]: An overview of the Hadoop/MapReduce/HBase framework and its current applications in bioinformatics
[7]: Cassandra - A Decentralized Structured Storage System
[8]: NOSQL Patterns
[9]: BigTable Model with Cassandra and HBase
[10]: LinkedIn Tech Talks : Apache Hadoop - Petabytes and Terawatts
[11]: O'Reilly Webcast: An Introduction to Hadoop
[12]: Google Developer Day : MapReduce
[13]: WSO2Con 2011 - Panel: Data, data everywhere: big, small, private, shared, public and more
[14]: Scaling with Apache Cassandra
[15]: HBase vs Cassandra: why we moved
[16]: A Brief History of NoSQL

Possible bug in iPad push notifications ?

2011-12-10T14:34:00.004+05:30

The applications that do support push notifications - will prompt a message whenever there is something to notify - even-though the user is not using the app at that time.

But - what if I have secured the iPad with a password.. Still these apps will prompt the message when iPad is in locked state.. Which looks like a bug for me..

Another possible bug.. when your iPad is locked and requires a password to unlock, still anyone can access your photos, just by clicking on the icon below..

May be iPad has some options to handle these scenarios - even in that case this shouldn't be the default behavior when iPad is protected with a password.

Symmetric/Asymmetric Encryption/Signature with Apache Rampart

2011-12-06T19:28:00.030+05:30

What is meant by Symmetric ? Both the parties, client and server use the same key to encrypt and sign.

Now the question is how to establish this key..? Anyone of the two parties can generate the key, but.. how do we pass the generated key to the other end...

This is how it works in Web Services security...

1. Initiator generates a key
2. Signs/Encrypts the message with the generated key
3. Encrypts the key with the public key of the recipient
4. Builds an encrypted key element with the output from [3] and associates an ID with that element and stores it in-memory using ID as the key. [This is how Rampart stores it]

<xenc:EncryptedKey Id="EncKeyId-C1AFA8321D1093CA1913231781007902">
    <xenc:EncryptionMethod
     Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <wsse:SecurityTokenReference>
      <wsse:KeyIdentifier
       EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
       ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">r3iHLvhEdbQLQGh0iuDzzJMBz40=</wsse:KeyIdentifier>
     </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
<xenc:CipherValue>O8LF2rEFKOJfKZpWlpmHI2OopDX00Ep4koqpJuEqhPbm3do1MTSovi0ZGl6wwtXYYCr3VzHobwDoc6yAECEoCEH9ZUvnzBKXa7OqmuGl3LOhIe91sTpHdceXbq7f6MpfePMPuHsdKhkbWea3aTOzbvzRm5VctZC7K4wk0LryBMQ=
     </xenc:CipherValue>
    </xenc:CipherData>
   </xenc:EncryptedKey>

5. EncryptedKey element will be included in the Security header of the SOAP message going from the sender to the recipient.

Here what you see under CipherValue element is the encrypted generated key.

The value of KeyIdentifier, which is r3iHLvhEdbQLQGh0iuDzzJMBz40=, is the base64 encoded SHA1 value of the fingerprint of the recipient's public key. Looking at this fingerprint value, recipient can pick the corresponding private key to decrypt the message and get the generated key out.

Also, let's have a look at the Algorithm attribute of EncryptionMethod element. This is the algorithm used to encrypt the generated key - and which to use is based on the Algorithm Suite defined in your security policy. In this case I have used Basic256 as the Algorithm Suite - so it uses rsa-oaep-mgf1p as the asymmetric key wrapping algorithm.

Now let's see what happens at the recipient end...

1. Recipient gets the message
2. Finds the private key corresponding to the fingerprint value in EncryptedKey element
3. Decrypts the encrypted generated key
4. Decrypts the message and verifies the signature using the key from [3]
5. Generates the response
6. Signs/Encrypts the response from the same key from [3]
7. Now it generates the SHA1 of the EncryptedKey element it receives from the client and adds the base64 encoded value to the response
8. Sends the response to the client

Once the client gets the message, it will perform following validations..

1. Client gets the message
2. Goes through all the stored EncryptedKey elements in-memory to check whether the SHA1 hash of any of them matches with the hash value in the response. If any match found, that's the Encrypted key.
3. EncryptedKey element in the memory also maintains the generated key in clear text, so client can find it
4. From the key found in [3]. client validates the message

With Symmetric binding, only the recipient needed to have a public/private key pair.

But in Asymmetric binding both the parties should have their own key pairs.

Even it's Asymmetric, the encryption happens with a generated symmetric key - the reason is Asymmetric encryption is resource consuming and also cannot operate on a large amount of data... so, WS-Security specification recommends to use symmetric key encryption with a generated key, even with the Asymmetric binding.

The major difference between the Asymmetric and the Symmetric is the way Signature been handled.

With Symmetric binding, both the request and the response are signed using the same generated key.. But in Asymmetric binding, the request is signed using the sender's private key and the response is signed using recipient's private key. In other words, Asymmetric provides a guarantee on non-repudiation while Symmetric binding does not.

Let's see how Asymmetric binding works in Web Services security..

1. Initiator/client generates a key
2. Encrypts the message with the generated key
3. Signs message with it's own private key
4. Encrypts the generated key with the public key of the recipient
5. Builds an encrypted key element with the output from [4] and associates an ID with that element. Do NOT store it in-memory as in the case of Symmetric.

<xenc:EncryptedKey Id="EncKeyId-C1AFA8321D1093CA1913231781007902">
    <xenc:EncryptionMethod
     Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p" />
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <wsse:SecurityTokenReference>
      <wsse:KeyIdentifier
       EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
       ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">r3iHLvhEdbQLQGh0iuDzzJMBz40=</wsse:KeyIdentifier>
     </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
<xenc:CipherValue>O8LF2rEFKOJfKZpWlpmHI2OopDX00Ep4koqpJuEqhPbm3do1MTSovi0ZGl6wwtXYYCr3VzHobwDoc6yAECEoCEH9ZUvnzBKXa7OqmuGl3LOhIe91sTpHdceXbq7f6MpfePMPuHsdKhkbWea3aTOzbvzRm5VctZC7K4wk0LryBMQ=
     </xenc:CipherValue>
    </xenc:CipherData>
   </xenc:EncryptedKey>

6. EncryptedKey element will be included in the Security header of the SOAP message going from the sender to the recipient.

The SOAP messages for Symmetric and Asymmetric requests look alike - cannot find any differences.

Now let's see what happens at the recipient end...

1. Recipient gets the message
2. Finds the private key corresponding to the fingerprint value in EncryptedKey element
3. Decrypts the encrypted generated key
4. Decrypts the message using the key from [3]
5. Verifies the signature of the message using the public key of the sender
6. Generates the response
7. Generates a new key
8. Encrypts the message with the generated new key
9. Signs message with it's own private key
10. Encrypts the generated key with the public key of the initiator [the client]
11. EncryptedKey element will be built with the encrypted generated key and included in the Security header of the SOAP message going from the service to the client.
12. Sends the response to the client

Once the client gets the message, it will perform following validations...

1. Client gets the message
2. Finds the private key corresponding to the fingerprint value in EncryptedKey element
3. Decrypts the encrypted generated key with the key from [2]
4. Decrypts the message using the key from [3]
5. Verifies the signature of the message using the public key of the service

One of my colleagues recently asked me how to find whether someone is using Asymmetric or Symmetric binding just by looking at the SOAP messages...

This is not possible by looking at the SOAP request - but looking at the SOAP response we can figure it out. When using Asymmetric binding SOAP response will have the EncryptedKey element inside the Security header - but not in the case of Symmetric binding.

Let's summarize the differences in the behavior between Asymmetric and Symmetric bindings.

	Symmetric Binding	Asymmetric Binding
Client	Generates a key	Generates a key
Service	Uses the same key generated from the client	Generates a key

Client	Stores the generated key	Does NOT store the generated key
Service	Does not generate keys	Does NOT store the generated key

Client	Encrypts with the generated key	Encrypts with the generated key
Service	Encrypts with the client generated key	Encrypts with the service generated key

Client	Signs with the generated key	Signs with the it's own private key
Service	Signs with the client generated key	Signs with the it's own private key

Client	Adds the EncryptedKey element to the request	Adds the EncryptedKey element to the request
Service	Does NOT add the EncryptedKey element to the response	Adds the EncryptedKey element to the response

Client	Signature algorithm hmac-sha1	Signature algorithm rsa-sha1
Service	Signature algorithm hmac-sha1	Signature algorithm rsa-sha1

Creating RESTful APIs Using the WSO2 Platform

2011-12-03T10:55:00.005+05:30

APIs have become an essential and key success factor for any business. Businesses do not operate as silos anymore, therefore each business depends on B2B communications. In technical terms, different systems/applications need to communicate with each other to fulfill various business requirements. Publishing rich business APIs is the answer to the above requirements.

Architects and developers who implement APIs prefer to use REST as the standard by looking at the simplicity and flexibility it provides for the end-users of the API and use lightweight message formats like JSON and POX. Most enterprises struggle to expose RESTful APIs due to various technical limitations and spend more time to architect and implement the same.

This half-day workshop focuses on how to expose your heterogeneous back-end services as a RESTful API in a quick and easy but architecturally accurate way, using the WSO2 Platform - and presented by Asanka Abeysinghe, Director, Solutions Architecture, WSO2.

Date : Thursday, 8 December - from 9.00 AM to 1.00 PM
Location : 4131, El Camino Real, Suite 200 Palo Alto, CA 94306
Admission : Free

Kolamba DZone Community Meetup

2011-12-01T16:33:00.005+05:30

The first ever DZone meetup in Sri Lanka happens on 15th December at WSO2 #58 office..

Sri Lanka has the highest number of Apace Committers out side USA and further in Google Summer of Code, University of Moratuwa - Sri Lanka was ranked as the top university Worldwide in terms of the number of awards received by students for the five year period from its inception in 2005. So, the interest among Sri Lankan tech community towards DZone Community Meetup undoubtedly expect to be very high...

We have picked "Big Data" as the theme for this meetup and have invited the experts in this area to share their thoughts.. All topics related to Big Data has lots of traction these days and DZone NoSQL Zone has a good collection of resources..

We would like to invite any of the DZone members/users around Colombo to join this meetup to share your thoughts..

WSO2 is happily sponsoring the event and we would expect DZone to send us some RefCards to share between the attendees..

Please confirm your attendance via http://www.meetup.com/DZoneVIP/Kolamba-LK/537342/

Location : WSO2, 5th Floor, 58 [ICIC Building], Dharmapala Mawatha, Colombo 07.

The depth of SAML [SAML Summary]

2011-11-26T02:34:00.013+05:30

1. History

Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between entities which is a product of the OASIS Security Services Technical Committee.

- SAML 1.0 was adopted as an OASIS standard in Nov 2002
- SAML 1.1 was ratified as an OASIS standard in Sept 2003
- SAML 2.0 became an OASIS standard in Mar 2005

Liberty Alliance donated its Identity Federation Framework (ID-FF) specification to OASIS, which became the basis of the SAML 2.0 specification. Thus SAML 2.0 represents the convergence of SAML 1.1, Liberty ID-FF 1.2, and Shibboleth 1.3.

2. SAML base standards

SAML is built upon the following technology standards.

- Extensible Markup Language (XML)
- XML Schema
- XML Signature
- XML Encryption (SAML 2.0 only)
- Hypertext Transfer Protocol (HTTP)
- SOAP

3. SAML Components

Assertions: Authentication, Attribute and Authorization information
Protocol: Request and Response elements for packaging assertions
Bindings: How SAML Protocols map onto standard messaging or communication protocols
Profiles: How SAML protocols, bindings and assertions combine to support a defined use case

4. Assertions and Protocols for SAML v2.0

The Security Assertion Markup Language (SAML) defines the syntax and processing semantics of assertions made about a subject by a system entity. In the course of making, or relying upon such assertions, SAML system entities may use other protocols to communicate either regarding an assertion itself, or the subject of an assertion. This specification defines both the structure of SAML assertions, and
an associated set of protocols, in addition to the processing rules involved in managing a SAML system. This specification is considered as the SAML Core specification and these constructs are typically embedded in other structures for transport, such as HTTP form POSTs and XML-encoded SOAP messages.

5. Bindings for SAML v2.0

Bindings for SAML specifies SAML protocol bindings for the use of SAML assertions and request-response messages in communications protocols and frameworks.

Mappings of SAML request-response message exchanges onto standard messaging or communication protocols are called SAML protocol bindings (or just bindings). An instance of mapping SAML requestresponse message exchanges into a specific communication protocol <FOO> is termed a binding for SAML or a SAML <FOO> binding. For example, a SAML SOAP binding describes how SAML request and response message exchanges are mapped into SOAP message exchanges.

The intent of this specification is to specify a selected set of bindings in sufficient detail to ensure that independently implemented SAML-conforming software can interoperate when using standard messaging or communication protocols.

Following bindings are covered under this specification.

- SAML SOAP Binding
- Reverse SOAP (PAOS) Binding
- HTTP Redirect Binding
- HTTP POST Binding
- HTTP Artifact Binding
- SAML URI Binding

6. Profiles for SAML v2.0

Profiles for SAML specifies profiles that define the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as profiles that define SAML attribute value syntax and naming conventions.

One type of SAML profile outlines a set of rules describing how to embed SAML assertions into and extract them from a framework or protocol. Such a profile describes how SAML assertions are embedded in or combined with other objects (for example, files of various types, or protocol data units of communication protocols) by an originating party, communicated from the originating party to a receiving party, and subsequently processed at the destination. A particular set of rules for embedding SAML assertions into and extracting them from a specific class of <FOO> objects is termed a <FOO> profile of SAML.

For example, a SOAP profile of SAML describes how SAML assertions can be added to SOAP messages, how SOAP headers are affected by SAML assertions, and how SAML-related error states should be reflected in SOAP messages.

Another type of SAML profile defines a set of constraints on the use of a general SAML protocol or assertion capability for a particular environment or context of use. Profiles of this nature may constrain optionality, require the use of specific SAML functionality (for example, attributes, conditions, or bindings), and in other respects define the processing rules to be followed by profile actors.

Following profiles are covered under this specification.

- SSO Profiles of SAML [Web Browser SSO Profile,Enhanced Client or Proxy (ECP) Profile, Identity Provider Discovery Profile, Single Logout Profile, Name Identifier Management Profile]
- Artifact Resolution Profile
- Assertion Query/Request Profile
- Name Identifier Mapping Profile
- SAML Attribute Profiles

7. Metadata for SAML v2.0

SAML profiles require agreements between system entities regarding identifiers, binding support and endpoints, certificates and keys, and so forth. A metadata specification is useful for describing this information in a standardized way. This specification defines an extensible metadata format for SAML system entities, organized by roles that reflect SAML profiles. Such roles include that of SSO Identity Provider, SSO Service Provider, Affiliation, Attribute Authority, Attribute Requester, and Policy Decision Point.

This specification further defines profiles for the dynamic exchange of metadata among system entities, which may be useful in some deployments.

8. Conformance Requirements for SAML v2.0

This normative specification describes features that are mandatory and optional for implementations claiming conformance to SAML V2.0 and also specifies the entire set of documents comprising SAML V2.0.

9. Web Services Security: SAML Token Profile 1.1

This specification describes how to use SAML V1.1 and V2.0 assertions with the Web Services Security SOAP Message Security V1.1 specification.

10. SAML 2.0 profile of XACML

The OASIS eXtensible Access Control Markup Language [XACML] is a powerful, standard
language that specifies schemas for authorization policies and for authorization decision requests and responses.

This profile defines how to use SAML 2.0 to protect, transport, and request XACML schema instances and other information needed by an XACML implementation.

11. Security and Privacy Considerations for SAML

This non-normative document describes and analyzes the security and privacy properties of SAML defined in the core SAML specification and the SAML bindings and profiles specifications.

12. SAML V2.0 Kerberos Attribute Profile

This specification defines an attribute profile for the Kerberos protocol. The SAML V2.0 Kerberos Attribute Profile describes a SAML attribute profile for requesting and expressing Kerberos protocol messages. In this version of the specification, this is constrained to the Kerberos KRB-CRED message type. The mechanisms that are used to generate the Kerberos message are outside the scope of this document and are described by IETF RFC 4120: 'The Kerberos Network Authentication Service (V5)'.

13. SAML V2.0 Change Notify Protocol

The SAML V2.0 Change Notify Protocol describes request and response messages for informing SAML endpoints about available changes to subjects and attributes associated with subjects.

SAML Assertions and XML Signature

2011-11-24T15:50:00.003+05:30

SAML assertions and SAML protocol request and response messages may be signed, with the following benefits:

1. An assertion signed by the SAML authority supports:
– Assertion integrity.
– Authentication of the SAML authority to a SAML relying party.
– If the signature is based on the SAML authority’s public-private key pair, then it also provides for non-repudiation of origin.

2. A SAML protocol request or response message signed by the message originator supports:
– Message integrity.
– Authentication of message origin to a destination.
– If the signature is based on the originator's public-private key pair, then it also provides for non-repudiation of origin.

The [1] talks about only signing the Assertion - and [2] talks about signing the request as well as the response message which also carries the Assertion.

A digital signature is not always required in SAML. For example, it may not be required in the following situations:

- In some circumstances signatures may be “inherited," such as when an unsigned assertion gains protection from a signature on the containing protocol response message. "Inherited" signatures should be used with care when the contained object (such as the assertion) is intended to have non-transitory lifetime. The reason is that the entire context must be retained to allow validation, exposing the XML content and adding potentially unnecessary overhead.

- The SAML relying party or SAML requester may have obtained an assertion or protocol message from the SAML authority or SAML responder directly (with no intermediaries) through a secured channel, with the SAML authority or SAML responder having authenticated to the relying party or SAML responder by some means other than a digital signature.

It is recommended that, in all other contexts, digital signatures be used for assertions and request and response messages. Specifically:

- A SAML assertion obtained by a SAML relying party from an entity other than the SAML authority SHOULD be signed by the SAML authority.
- A SAML protocol message arriving at a destination from an entity other than the originating site SHOULD be signed by the origin site.

XML Signatures are intended to be the primary SAML signature mechanism.

Unless a profile specifies an alternative signature mechanism, enveloped XML Digital Signatures MUST be used if signing. This is bit different from the signature pattern recommended in WS-Security specification.

WS-Security specification says..

"Because of the mutability of some SOAP headers, producers SHOULD NOT use the Enveloped Signature Transform defined in XML Signature. Instead, messages SHOULD explicitly include the elements to be signed. Similarly, producers SHOULD NOT use the Enveloping Signature defined in XML Signature".

Although this contrasts with what is recommended in SAML specification - WS-Security doesn't have nothing to with SAML. SAML becomes a token type for WS-Security and SAML specification has the full control to define it's own recommendation for signing.

Why SAML specification recommends enveloped signature?

With enveloped signature, the signature element will be inside the element been signed it self - which is the Assertion element.

Enveloped signature is useful when we have a signed XML document that we wish to insert into other XML documents. Which is the case with SAML Assertion. There you get the SAML Assertion from the issuer and include it in to a request to the service provider.

SAML implementations also SHOULD use Exclusive Canonicalization [Excl-C14N], with or without comments, both in the element of , and as a algorithm. Use of Exclusive Canonicalization ensures that signatures created over SAML messages embedded in an XML context can be verified independent of that context.

Exclusive Canonicalization tries to figure out what namespaces you are actually using and just copies those. Specifically, it copies the ones that are "visibly used", which means the ones that are a part of the XML syntax. However, it does not look into attribute values or element content, so the namespace declarations required to process these are not copied. For example if you had an attribute like xx:foo="yy:bar" it would copy the declaration for xx, but not yy. It also does not copy the xml: attributes that are declared outside the scope of the signature.

Exclusive Canonicalization allows you to create a list of the namespaces that must be declared, so that it will pick up the declarations for the ones that are not visibly used.

Exclusive Canonicalization is useful when you have a signed XML document that you wish to insert into other XML documents - as in a signed SAML assertion which might be inserted as a XML Token in the security header of various SOAP messages. The Issuer who signs the assertion will be aware of the namespaces being used and able to construct the list. The use of Exclusive Canonicalization will insure the signature verifies correctly every time.

In contrast, the Inclusive Canonicalization copies all the declarations that are currently in force, even if they are defined outside of the scope of the signature. It also copies any xml: attributes that are in force, such as xml:lang or xml:base. This guarantees that all the declarations you might make use of will be unambigiously specified. The problem with this is that if the signed XML is moved into another XML document which has other declarations, the Inclusive Canonicalization will copy them and the signature will be invalid. This can even happen if you simply add an attribute in a different namespace to the surrounding context.

References :
1. http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
2. http://lists.oasis-open.org/archives/wss/200311/msg00058.html

Key Exchange Patterns with Web Services Security

2011-11-21T17:25:00.001+05:30

When we have message level security with web services - how we achieve integrity and confidentiality is through keys. Keys are used to sign and encrypt messages been passed from the rqeuestor to the recipient or form the client to the service and vise versa.

During this blog post, we'll be discussing different key exchange patterns and their related use cases.

1. Direct Key Transfer

If one party has a token and key and wishes to share this with another party, the key can be directly transferred. WS-Secure Conversation is a good example for this. Under WS-Secure Conversation, when the security context token is created by one of the communicating parties and propagated with a message it occupies this pattern to do the key exchange. This is accomplished by the initiator sending an RSTR (either in the body or header) to the other party. The RSTR contains the token and a proof-of-possession token that contains the key encrypted for the recipient.

The initiator creates a security context token and sends it to the other parties on a message using the mechanisms described in WS-Trust specification. This model works when the sender is trusted to always create a new security context token. For this scenario the initiating party creates a security context token and issues a signed unsolicited <wst:RequestSecurityTokenResponse> to the other party. The message contains a <wst:RequestedSecurityToken> containing (or pointing to) the new security context token and a <wst:RequestedProofToken> pointing to the "secret" for the security context token.

2. Brokered Key Distribution

A third party MAY also act as a broker to transfer keys. For example, a requestor may obtain a token and proof-of-possession token from a third-party STS. The token contains a key encrypted for the target service (either using the service's public key or a key known to the STS and target service). The proof-of-possession token contains the same key encrypted for the requestor (similarly this can use public or symmetric keys).

WS-Secure Conversation also has an example for this pattern when the security context token is created by a security token service – The context initiator asks a security token service to create a new security context token. The newly created security context token is distributed to the parties through the mechanisms defined here and in WS-Trust. For this scenario the initiating party sends <wst:RequestSecurityToken> request to the token service and a <wst:RequestSecurityTokenResponseCollection> containing a <wst:RequestSecurityTokenResponse> is returned. The response contains a <wst:RequestedSecurityToken> containing (or pointing to) the new security context token and a <wst:RequestedProofToken> pointing to the "secret" for the returned context. The requestor then uses the security context token when securing messages to applicable services.

3. Delegated Key Transfer

Key transfer can also take the form of delegation. That is, one party transfers the right to use a key without actually transferring the key. In such cases, a delegation token, e.g. XrML, is created that identifies a set of rights and a delegation target and is secured by the delegating party. That is, one key indicates that another key can use a subset (or all) of its rights. The delegate can provide this token and prove itself (using its own key – the delegation target) to a service. The service, assuming the trust relationships have been established and that the delegator has the right to delegate, can then authorize requests sent subject to delegation rules and trust policies.

For example a custom token is issued from party A to party B. The token indicates that B (specifically B's key) has the right to submit purchase orders. The token is signed using a secret key known to the target service T and party A (the key used to ultimately authorize the requests that B makes to T), and a new session key that is encrypted for T. A proof-of-possession token is included that contains the session key encrypted for B. As a result, B is effectively using A's key, but doesn't actually know the key.

4. Authenticated Request/Reply Key Transfer

In some cases the RST/RSTR mechanism is not used to transfer keys because it is part of a simple request/reply. However, there may be a desire to ensure mutual authentication as part of the key transfer. The mechanisms of WS-Security can be used to implement this scenario.

Specifically, the sender wishes the following:
- Transfer a key to a recipient that they can use to secure a reply
- Ensure that only the recipient can see the key
- Provide proof that the sender issued the key

This scenario could be supported by encrypting and then signing. This would result in roughly the following steps:

1. Encrypt the message using a generated key
2. Encrypt the key for the recipient
3. Sign the encrypted form, any other relevant keys, and the encrypted key

However, if there is a desire to sign prior to encryption then the following general process is used:

1. Sign the appropriate message parts using a random key (or ideally a key derived from a random key)
2. Encrypt the appropriate message parts using the random key (or ideally another key derived from the random key)
3. Encrypt the random key for the recipient
4. Sign just the encrypted key

Most part of this blog post is extracted from WS-Trust 1.4 specification.

Understanding Entropy

2011-11-20T16:20:00.008+05:30

This blog post is inspired by a question asked from one of my team mates - so.. here I am trying to explain what is entropy and it's role in web services security.

In information theory, entropy is a measure of the uncertainty associated with a random variable. In other words, entropy adds randomness to a generated key.

In WS-Trust, under Holder-of-Key scenario - the Security Token Service has to generate a key and pass that to the client - which will later be used between the client and the service to secure the communication.

Let's see how this is done.. Let's have a look at some part of the client request to the Security Token Service.

<wst:Entropy>
    <wst:BinarySecret
     Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce">nVY8/so9I3uvI3OSXDcyb+9kxWxMFNiwzT7qcsr5Hpw=
    </wst:BinarySecret>
   </wst:Entropy>
   <wst:ComputedKeyAlgorithm>http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1</wst:ComputedKeyAlgorithm>

Here you can see, the Entropy element is included in the request.

This optional element allows a requestor to specify entropy that is to be used in creating the key. The value of this element should be either a <xenc:EncryptedKey> or <wst:BinarySecret> depending on whether or not the key is encrypted. Secrets should be encrypted unless the transport/channel is already providing encryption. The BinarySecret element specifies a base64 encoded sequence of octets representing the requestor's entropy.

The keys resulting from a request are determined in one of three ways...

1. Specific
2. Partial
3. Omitted

In the case of specific keys, a <wst:RequestedProofToken> element is included in the response which indicates the specific key(s) to use unless the key was provided by the requestor(in which case there is no need to return it). This happens if the requestor does not provide entropy or issuer rejects the requestor's entropy.

In the case of partial, the <wst:Entropy> element is included in the response, which indicates partial key material from the issuer (not the full key) that is combined (by each party) with the requestor's entropy to determine the resulting key(s). In this case a <wst:ComputedKey> element is returned inside the <wst:RequestedProofToken> to indicate how the key is computed. This happens if the requestor provides entropy and the issuer honors it. Here you will see, in the response it will have an Entropy element - which includes the issuer's entropy.

<wst:RequestedProofToken>
    <wst:ComputedKey>http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1
    </wst:ComputedKey>
   </wst:RequestedProofToken>
   <wst:Entropy>
    <wst:BinarySecret
     Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce">3nBXagllniQA8UEAs5uRVJFrKb9dPZITK76Xk/XCO5o=
    </wst:BinarySecret>
   </wst:Entropy>

In the case of omitted, an existing key is used or the resulting token is not directly associated with a key. This happens if the requestor provides entropy and the responder doesn't (issuer uses the requestor's key), then a proof-of-possession token need not be returned.

Following table summarizes the use of Entropy.

Requestor	Issuer	Result
Provides Entropy	Uses requestor entropy as key	No proof-of-possession token is returned
Provides Entropy	Provides entropy	No keys returned, key(s) derived using entropy from both sides according to method identified in response. Issuer's Entropy is returned to the client and the way the key was derived specified under ComputedKey element.
Provides Entropy	Issues own key (rejects requestor's entropy)	Proof-of-possession token contains issuer's key(s)
No Entropy provided	Issues own key	Proof-of-possession token contains issuer's key(s)
No Entropy provided	Does not issue key	No proof-of-possession token

Subject Confirmation support with Apache Rampart : Holder-of-Key

2011-11-15T19:04:00.008+05:30

The Subject Confirmation is the process of establishing the correspondence between the subject and claims of SAML statements (in SAML assertions) and SOAP message content by verifying the confirmation evidence provided by an attesting entity.

SAML 1.1 Token Profile talks about three subject confirmation methods.

1. Holder-of-key Subject Confirmation Method
2. Bearer-key Subject Confirmation Method
2. Sender-vouches Subject Confirmation Method

With Holder-of-key Subject Confirmation Method, the attesting entity demonstrates that it is authorized to act as the subject of a holder-of-key confirmed SAML statement by demonstrating knowledge of any key identified in a holder-of-key SubjectConfirmation element associated with the statement by the assertion containing the statement. Statements attested for by the holder-of-key method MUST be associated, within their containing assertion, with one or more holder-of-key SubjectConfirmation elements.

Let's see how this works..

First the client application needs to request a token from the Security Token Service or the STS. This request is known as RST [wst:RequestSecurityToken] and goes inside the SOAP Body. Following is a sample RST.

   xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
   http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
   
   
         xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
     http://localhost:8280/services/echo
    
   
   
         xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2011-11-15T10:29:17.487Z
         xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2011-11-15T10:34:17.487Z
   
   http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1
   
   http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey
   
   256
   
         Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce">nVY8/so9I3uvI3OSXDcyb+9kxWxMFNiwzT7qcsr5Hpw=
    
   
   http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1

Let's have a look at some of the key elements in the RST.

1. AppliesTo

This is the end point where the client going to use this token against.

2. KeyType : http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey

Use Symmetric key when generating the key for the SubjectConfirmation.

3. KeySize

Use this key size when generating the key for the SubjectConfirmation.

4. Entropy/BinarySecret

WS-Trust allows the requestor to provide input to the key material via a wst:Entropy element in the request. The requestor might do this to satisfy itself as to the degree of entropy (cryptographic randomness if you will) of at least some of the material used to generate the actual key which is used for SubjectConfirmation.

5. Entropy/ComputedKeyAlgorithm : http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1

The key derivation algorithm to use if using a symmetric key for P, where P is computed using client, server, or combined entropy.

With http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1 the key is computed using P_SHA1 from the TLS specification to generate a bit stream using entropy from both sides. The exact form is:
key = P_SHA1 (EntREQ, EntRES)
It is RECOMMENDED that EntREQ be a string of length at least 128 bits.

Now let's see how this request been processed at the STS end.

Based on the Key Type in the request - STS will decide whether to use Holder-of-key or not. For following key types, holder-of-key subject confirmation method will be used.

1. http://docs.oasis-open.org/ws-sx/ws- trust/200512/PublicKey
2. http://docs.oasis-open.org/ws-sx/ws- trust/200512/SymmetricKey

If it is SymmetricKey - then STS will generate a key - encrypt the key using the public certificate corresponding to the end point attached to the AppliesTo element in the RST and add that to the SubjectConfirmation element in the response.

Key generation is once again bit tricky.

If client provides an entropy and the key computation algorithm is http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1 then, the key is generated as a function of the client entropy and the STS entropy.

If client provides an entropy but the key computation algorithm is NOT http://schemas.xmlsoap.org/ws/2005/02/trust/CK/PSHA1 then, the key is same as the client entropy.

If neither of above happens, then the server generates an ephemeral key.

Whatever the way the key is generated, it will be encrypted with the certificate corresponding to the AppliesTo end point and will be added in to the SubjectConfirmation element in the response.


        urn:oasis:names:tc:SAML:1.0:cm:holder-of-key
        
        
                   Id="EncKeyId-3C611397F54EB4BEF913213415708916">
                     Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
          
                       xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                         EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
             ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">Ye9D13/K1GFRvJjgw1kSr5/rYxE=
           
          
          
           a/kALeV0b0Y3oNcE7fdepUuF0sbQUGs012r87BMBUx/FL8Hc+kw/BGrRThEGGmDmVgJ8GdJw34nQM6IjulNV+hj/MmtXLSKZnjm7uLPPT3kgT0udzc8OuSgLVRO8ghcDK12/IiPAtzWZIfPS/ZT8kx4DSYWnvcNa4mTMM4wBhjt29bvAJcKZD0CqvJOLIFWc2FrQqNkym4UIF+GEcsN3rQcYDzoyiCm2L4RAm3u+1d+9zsQIEo8DtqDDboA0MAVbbM6xU3JbF35dLifmpwlsuiJC0y8VlAoN6wnNIJ/tpr4C4FhvdKnShAOeDf3D2JkZxr4ZNZZL91aHFaPpFbC9YQ==

As per the above code, what you see inside CipherValue element is the encrypted key. And it is encrypted from a certificate which is having the thumbprint reference Ye9D13/K1GFRvJjgw1kSr5/rYxE=. In other words, only the service which owns the certificate having the thumbprint reference Ye9D13/K1GFRvJjgw1kSr5/rYxE= would be able to decrypt the key - which is in fact the service end point attached to the AppliesTo element. BTW... can anybody in the middle fool the service endpoint just by replacing the SubjectConfirmation element..? This is prevented by STS signing the SubjectConfirmation element along with Assertion parent element with it's private key. So - the SAML token is protected for integrity.

Okay... now the token is at the client end... In which ways the client application going to use this token.

One way is to use it as a SupportingToken and the other way is to use it as a ProtectionToken.

When we use SAML token as a ProtectionToken, client application can use it to encrypt/sign the messages going from the client to the service end point. Then the question is which key would the client use to sign and encrypt - it's the same key added to the SubjectConfirmation by the STS - but it's encrypted with the public key of the service end point - so, client won't be able to decrypt it and get access to the hidden key.

There is another way, STS passes the generated key to the client. Let's look at the following element also included in the response passed from the STS to the client - this is out side the Assertion element.

<wst:Entropy>
    <wst:BinarySecret
     Type="http://schemas.xmlsoap.org/ws/2005/02/trust/Nonce">3nBXagllniQA8UEAs5uRVJFrKb9dPZITK76Xk/XCO5o=
    </wst:BinarySecret>
   </wst:Entropy>

Here in the Entropy/BinarySecret STS passed the entropy created to generate the key. The key is generated as a function of the client entropy and the STS entropy - client already knows the client entropy and can find the STS entropy inside Entropy/BinarySecret in the response - so, client can derive the key from those.

Following would be the WS-Security Policy at the service end, which expects SAML token as a ProtectionToken.

<wsp:Policy wsu:Id="SgnOnlyAnonymous"
 xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
 xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
 <wsp:ExactlyOne>
  <wsp:All>
   <sp:SymmetricBinding>
    <wsp:Policy>
     <sp:ProtectionToken>
      <wsp:Policy>
       <sp:IssuedToken
        sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
        <Issuer xmlns="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
         <Address xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/axis2/services/STS
         </Address>
        </Issuer>
        <sp:RequestSecurityTokenTemplate>
         <t:TokenType xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1
         </t:TokenType>
         <t:KeyType xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey
         </t:KeyType>
         <t:KeySize xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">256</t:KeySize>
        </sp:RequestSecurityTokenTemplate>
        <wsp:Policy>
         <sp:RequireInternalReference />
        </wsp:Policy>
       </sp:IssuedToken>
      </wsp:Policy>
     </sp:ProtectionToken>
     <sp:AlgorithmSuite>
      <wsp:Policy>
       <sp:Basic128 />
      </wsp:Policy>
     </sp:AlgorithmSuite>
     <sp:Layout>
      <wsp:Policy>
       <sp:Lax />
      </wsp:Policy>
     </sp:Layout>
     <sp:IncludeTimestamp />
     <sp:OnlySignEntireHeadersAndBody />
    </wsp:Policy>
   </sp:SymmetricBinding>
   <sp:SignedParts>
    <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing" />
    <sp:Body />
   </sp:SignedParts>
   <sp:Wss11>
    <wsp:Policy>
     <sp:MustSupportRefKeyIdentifier />
     <sp:MustSupportRefIssuerSerial />
     <sp:MustSupportRefThumbprint />
     <sp:MustSupportRefEncryptedKey />
     <sp:RequireSignatureConfirmation />
    </wsp:Policy>
   </sp:Wss11>
   <sp:Trust10>
    <wsp:Policy>
     <sp:MustSupportIssuedTokens />
     <sp:RequireClientEntropy />
     <sp:RequireServerEntropy />
    </wsp:Policy>
   </sp:Trust10>
  </wsp:All>
 </wsp:ExactlyOne>
</wsp:Policy>

When we use the SAML token as a SupportingToken, we basically doing nothing from it that sending it as it is to the service end in the SOAP Security Header. SubjectConfirmation goes useless here - but service end can verify whether the token been issued by a trusted STS, by verifying the signature.

Following is the WS-Security Policy at the service end - which expects SAML token as a SupportingToken.

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
 xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
 wsu:Id="SigEncr">
 <wsp:ExactlyOne>
  <wsp:All>
   <sp:SupportingTokens
    xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
    <wsp:Policy>
     <sp:IssuedToken
      sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
      <Issuer xmlns="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
       <Address xmlns="http://www.w3.org/2005/08/addressing">
        https://localhost:9443/services/wso2carbon-sts
       </Address>
      </Issuer>
      <sp:RequestSecurityTokenTemplate
       xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
       <t:TokenType>
        urn:oasis:names:tc:SAML:1.0:assertion</t:TokenType>
       <t:KeyType>
        http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey
       </t:KeyType>
       <t:KeySize>256</t:KeySize>
       <t:Claims Dialect="http://wso2.org/claims"
        xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity">
        <ic:ClaimType Uri="http://wso2.org/claims/givenname" />
       </t:Claims>
      </sp:RequestSecurityTokenTemplate>
      <wsp:Policy>
       <sp:RequireInternalReference />
      </wsp:Policy>
     </sp:IssuedToken>
    </wsp:Policy>
   </sp:SupportingTokens>
  </wsp:All>
 </wsp:ExactlyOne>
</wsp:Policy>

Cross Domain Authentication Patterns - Kerberos with STS

2011-11-09T20:35:00.004+05:30

Business Requirements :

1. Users from domain A - need to access a service in domain B
2. Not all the users from domain A should be able to access the service in domain B [only a given group of users]
3. Users are in a Windows domain and should be not asked again to enter any credentials to access the service in domain B

What we need to achieve is..

User logs in to his Windows machine and seamlessly accesses the service in domain B - with no additional authentication steps.

Pattern - as per the diagram above..

1 & 2 : User talks to Kerberos KDC [TGS] - authenticates and gets a Kerberos TGT. This communication with KDC happens underneath when user logs in to his Windows machine.

3 & 4 : User program using the TGT, gets a Kerberos ticket to access the STS.

5 & 6 : Using the Kerberos ticket issued to the user to access the STS - user program authenticates to STS and obtains a SAML token via WS-Trust. STS also carries out an authorization check to see whether the user is eligible to access the service in domain B.

7 & 8 : User program uses the obtained SAML token to authenticate to the service in domain B. The service will validate that the token is issued from a trusted STS by verifying the signature.

Claim based authorization with WSO2 Identity Server

2011-11-09T02:23:00.005+05:30

This blog post explains how to set up WSO2 Identity Server to do claim based authorization with XACML.

1. Download WSO2 Identity Server latest version from here.

2. The default user store of WSO2 Identity Server is running on an embedded ApacheDS server. In case you need to point it to an external LDAP server you can do it through a change in the configuration. This blog post explains how to integrate Oracle Directory Server as the User Store of WSO2 Identity Server.

3. Start the WSO2 Identity Server from [IS_HOME]\bin

4. Let's now define our authorization policy in plain English.

"A given resource can be accessed only by any user having an email address from wso2 belonging to a particular role and all the requests to any other resource other than this should fail"

5. Save the following policy in to a local file and import the file to WSO2 Identity Server XACML engine. Main --> Entitlement --> Administration --> Import New Entitlement Policy --> File System and import the policy. Then from policy list view click on the Enable button against the uploaded policy to enable the policy.


  
    
      
        
          
            read
            
          
        
      
      
        
          
            @wso2.com$
            
          
        
      
    
    
      
        
        admin
        
      
    
  
  
  
    
      
        
          http://localhost:8080/services/echo/

6. Looking at the policy, you might have noticed that, I have used the claim http://wso2.org/claims/emailaddress. And, this should map to the attribute id, corresponding to the email, in the underlying user store. If it is LDAP then, http://wso2.org/claims/emailaddress should map to the 'mail' attribute id. This is done through the Claim Management UI,

7. Configure --> Claim Management --> http://wso2.org/claims

8. Now you can see all the claims used under wso2.org dialect

9. Click on Edit link against any of the claims you want to update and then set the "Mapped Attribute" value to the, attribute id name from the underlying user store.

10. You can try the policy we defined, from the Entitlement TryIt tool. Main --> Entitlement --> TryIt.

ApacheCon Vancouver : Training on Web Services Security

2011-11-07T17:05:00.044+05:30

Today is the first day at ApacheCon 2011 @ Vancouver - Canada.

My training on Web Services Security started around 2.30 in the afternoon.

First part was a presentation on different security patterns and standards - then started digging in to the Rampart code.

All the samples I used are available here. You can use a simple SVN client to get that code. It comes as Eclipse projects and when loaded in to an Eclipse workspace, just set the SAMPLES_HOME environment variable in ECLIPSE to the root of the downloaded code - it should build fine then... Following are some of the resources that you can look in to..

1. http://RampartFAQ.com
2. Understanding WS – Security Policy Language
3. Applying policies at binding hierarchy
4. Password Callback Handlers Explained
5. SAML Bearer Confirmation Method, Sender Vouches & Holder-of-Key
6. Identity Delegation in WS Trust 1.4
7. WS Security Policy – Asymmetric Binding Explained

Cloud Security Videos

2011-10-28T03:19:00.001+05:30

Open Source for Cyber Security

2011-10-28T03:09:00.006+05:30

@4th Annual National Conference on Cyber Security, Colombo

"Security in the Cloud" - Webinar

2011-10-28T03:04:00.003+05:30

"Security in Practice" @ WSO2Con 2011

2011-09-15T08:05:00.001+05:30

View more presentations from Prabath Siriwardena.

Facebook unfriend app demoed during the second day of WSO2Con

2011-09-15T07:59:00.002+05:30

It's was a perfect demo on WSO2 StratosLive [Java PaaS] by Shankar which included developing and deploying cloud applications in front of a huge audience. Everything went perfect and Shankar was honored with a thundering applause.

During his demo, Shankar also demonstrated the "Catch who didn't match you" application - which let you find who unfriended you in Facebook.

"Catch Who Didn't Match You..." - Facebook unfriend finder on WSO2 StratosLive...!!!

2011-09-12T06:12:00.005+05:30

The word "unfriend" was named as the word of year 2009 by the Oxford Dictionary.

unfriend – verb – To remove someone as a ‘friend’ on a social networking site such as Facebook.

The Facebook, the most popular social networking site, doesn't offer a straight forward way to figure out who removed you there.

The "Catch Who Didn't Match You" application caters exactly that. Currently it's running on WSO2 StrtosLive PAAS and backed by a highly scalable cassandra NoSQL data store - available via http://tinyurl.com/stratos-unfriend.

The WSO2 Identity Server @ NBQSA 2011

2011-08-24T18:22:00.002+05:30

The SMALL miracle, ready for her BIGGEST IT event forever

2011-08-24T12:02:00.004+05:30
As any of the WSO2ers, me too excited...

Internal mailing lists getting busier and busier.. plenty of suggestions... thoughts... and ideas... everyone talking about making the WSO2Con an unique - unmatched experience.

This is not just the BIGGEST event WSO2 has ever organized, but the BIGGEST IT event in Sri Lanka..

WSO2Con happened to be an annual event since our 5th anniversary last year and this is the first time we've added 'international' flavor on it.

It's non-second to ApacheCon..

It's non-second to OSCON...

WSO2Con this year, features more than 30 experienced speakers around the world, from more than ten countries.

Dr. Mohan from IBM, Sastry Malladi from eBAy, Gregor Hohpe from Google are few to name among them.

Dr. C. Mohan has been an IBM researcher for 30 years in the information management area, impacting numerous IBM and non-IBM products, the research community and standards, especially with his invention of the ARIES family of locking and recovery algorithms, and the Presumed Abort commit protocol.

This IBM, ACM and IEEE Fellow has also served as the IBM India Chief Scientist. In addition to receiving the ACM SIGMOD Innovation Award, the VLDB 10 Year Best Paper Award and many IBM awards, he has been elected to the US and Indian National Academies of Engineering, and has been named an IBM Master Inventor. This distinguished alumnus of IIT Madras received his PhD at the University of Texas at Austin. He is an inventor of 36 patents. He serves on the advisory board of IEEE Spectrum and on the IBM Software Group Architecture Board’s Council.

Sastry is a technology evangelist with over 20 years of experience in architecting and building scalable distributed computing systems, in the areas of Application Servers, Java/J2EE/Web Services, SOA and Grid Computing. He is currently a Distinguished Architect at eBay, driving the SOA architecture and platform for the eBay ecommerce platform.

Prior to joining eBay, Sastry was Co-Founder and CTO of OpenGridSolutions, Founding member and Architect at SpikeSource, and an Architect at Oracle. Sastry also worked at many other companies in the early stages of his career and holds a Masters degree from I.I.T, Kharagpur, India. Sastry has presented at many conferences including JavaOne, Oracle World, SOA world and IONA world to name a few. He is a contributor to many standards at OMG, JCP, GGF and OASIS.

Gregor Hohpe is a Staff Software Engineer with Google. As a widely recognized thought leader on asynchronous messaging and service-oriented architectures. he co-authored the seminal book ‘Enterprise Integration Patterns’ (Addison-Wesley, 2004) and contributed to a variety of publications, including “97 Things Every Architect Should Know”. In 2005, Joel Spolsky selected Gregor’s article ‘Starbucks Does Not Use Two-phase Commit’ for his ‘Best Software Writing’. Find out more about his work at eaipatterns.com.

Doesn't this provide enough excitement to attend WSO2Con this year..? Here comes more.. :-)

It's in Sri Lanka - the 'small miracle' - surrounded with beautiful blue ocean, rich with enchanting natural beauty and smiles all-around from a nation renowned for great hospitality.

Also the biggest book fair in Sri Lanka, with hundreds of international publishers, will commence just after the WSO2Con - on 17th September - and will be within 5 kilometers from the conference center. This year it's the 13th Colombo International Book Fair and so far, every-time - this attracted crowds going beyond hundred thousands.

More news on WSO2Con to follow.. please keep tune in...

ApacheCon 2011 : Web Services Security - Patterns, Practices and Threats

2011-07-07T07:43:00.000+05:30
I'll be conducting a training on "Web Services Security - Patterns, Practices and Threats" at ApacheCon this time. Would be on 7th November from 2.30 PM to 5.30 PM. If you are planning to attend ApacheCon, now it's open for registration.

During this session I'll be covering the practical importance of security standards like, WS-Security, WS-Security Policy, WS-Trust and risks associated with those. Further the session will cover patterns, best practices and threats associated with SOA security models.

Integrating 3-legged OAuth with XACML

2011-07-06T17:13:00.020+05:30
This blog post explains in detail how to integrate 3-legged OAuth with XACML. Detailed explanations on OAuth and XACML are out of scope.

You need to download following products to get the sample running.

1. WSO2 Identity Server - acting as the service provider, where a user can register an OAuth consumer app to obtain a request token, authorize it and obtain an access token. Also WSO2 Identity Server is used as the XACML engine. Identity Server can be downloaded from here.

2. WSO2 ESB - acting as an interceptor to the final resource the consumer wants to access. ESB will intercept the request and performs OAuth validation. WSO2 ESB can be downloaded from here.

3. WSO2 Application Server - this is used to host WSO2 OAuth Playground web app. App Server can be downloaded from here.

4. Download and unzip the sample from here to OAUTH_SAMPLE.

Let's first start by setting up the WSO2 Identity Server.

1. Unzip the downloaded copy of Identity Server and remove all jars starting with org.wso2.carbon.identity.oauth inside [IS_HOME]\reposiroty\components\plugins

2. Copy following jars from OAUTH_SAMPLE\dropins to [IS_HOME]\reposiroty\components\dropins
org.wso2.carbon.identity.oauth-3.2.1.jar
org.wso2.carbon.identity.oauth.stub-3.2.1.jar
org.wso2.carbon.identity.oauth.ui-3.2.1.jar

3. Above [1] & [2] steps are not required when OAuth 3.2.1 feature is available in WSO2 feature repo - you can simply point there and update.

4. Start WSO2 Identity Server

5. Login as admin/admin and go to OAuth and register a consumer application. When creating the application make sure you give http://localhost:9767/playground/oauth/oauth_callback as the callback url. This is the location we are going to setup our sample web app later.

6. Also - once created the app - click on the link under you application name - there you can see the corresponding consumer key and the consumer secret for your app.

7. Now we need to setup the XACML engine in WSO2 Identity Server

9. Go to Entitlement --> Administration --> Import Policy --> Select file system and import the policy OAUTH_SAMPLE/xacml.policy

10. Once imported - make sure you click on the ENABLE link against the imported policy.

11. That completes the Identity Server setup.

Now, let's setup WSO2 ESB.

1. Unzip the downloaded copy of WSO2 ESB and remove all jars starting with org.wso2.carbon.identity.oauth inside [ESB_HOME]\reposiroty\components\plugins

2. Copy following jars from OAUTH_SAMPLE\dropins to [ESB_HOME]\reposiroty\components\dropins
org.wso2.carbon.identity.oauth.mediator-3.2.1.jar
org.wso2.carbon.identity.oauth.stub-3.2.1.jar

3. Above [1] & [2] steps are not required when OAuth 3.2.1 feature is available in WSO2 feature repo - you can simply point there and update.

4. Open ESB_HOME\repository\conf\carbon.xml and find for the element Offset and set it to 2.
This will make sure that ESB starts on ports 9445/9765.

5. Start WSO2 ESB

6. Login as admin/admin and replace the synapse configuration in the source view - with the content from OAUTH_SAMPLE\synapse.xml

7. That's it and we are done with the ESB.

Let's set up the sample web app with WSO2 Application Server.

1. Open AS_HOME\repository\conf\carbon.xml and find for the element Offset and set it to 4.
This will make sure that App Server starts on ports 9447/9767.

2. Copy OAUTH_SAMPLE\playground.war to AS_HOME\repository\deployment\server\webapps

3. Start WSO2 Application Server

Now let's see how web app works.

1. Go to http://localhost:9767/playground

2. To get the request token, type your consumer key and consumer secret corresponding to your registered oauth application. Set the scope as echoService [should be the exact name, since that is what is been referred in the XACML policy].

3. Once you get the request token, you need to get that authorized by the user.

4. After that you can exchange the authorized token to an access token.

5. Copy the value of oauth_token from the response to [4] - we need this value when we are going to access the resource.

Now let's try to invoke a service with the obtained access token. Following java code explains how to do that. You need replace the values of CONSUMER_SECRET,CONSUMER_KEY and OAUTH_TOKEN. The value of OAUTH_TOKEN is the one you got with the access token.
package org.wso2.rest.security.oauth;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;

import com.google.gdata.client.GoogleService;
import com.google.gdata.client.Service.GDataRequest;
import com.google.gdata.client.authn.oauth.GoogleOAuthParameters;
import com.google.gdata.client.authn.oauth.OAuthHmacSha1Signer;

public class OauthClient {

private static final String ESB = "http://127.0.0.1:8280/";

/**
* @param args
*/
public static void main(String[] args) {

final String CONSUMER_SECRET = "9FXwlWNQdUlG2rWk7os3VRz8dfsa";
final String CONSUMER_KEY = "yumx9s1HAf1iaItr1UZw4afEEjga";
final String OAUTH_TOKEN = "hfiYq1ppu3VhLsFWxpFjCUDc3Jwa";

GDataRequest request = null;

try {

GoogleOAuthParameters oauthParameters = new GoogleOAuthParameters();
oauthParameters.setOAuthConsumerKey(CONSUMER_KEY);
oauthParameters.setOAuthConsumerSecret(CONSUMER_SECRET);
oauthParameters.setOAuthToken(OAUTH_TOKEN);

OAuthHmacSha1Signer signer = new OAuthHmacSha1Signer();
GoogleService service = new GoogleService("demoservice", "myapp");
service.setOAuthCredentials(oauthParameters, signer);
String param = "hi";
String baseString = ESB + "services/oauth_proxy/echoString" + "?xoauth_requestor_id="
+ CONSUMER_KEY + "&in=" + param + "&scope=echoService";
URL feedUrl = new URL(baseString);
request = service.createFeedRequest(feedUrl);
request.execute();
System.out.println(convertStreamToString(request.getResponseStream()));
} catch (Exception e) {
e.printStackTrace();
}
}

private static String convertStreamToString(InputStream is) throws IOException {
if (is != null) {
StringBuilder sb = new StringBuilder();
String line;
try {
BufferedReader reader = new BufferedReader(new InputStreamReader(is, "UTF-8"));
while ((line = reader.readLine()) != null) {
sb.append(line).append("\n");
}
} finally {
is.close();
}
return sb.toString();
} else {
return "";
}
}

}

To run the above client you need to have google-collect and gdata-core jars in your classpath.

Fine-grained Authorization with XACML

2011-04-23T09:05:00.002+05:30

XACML Policy Information Point Extensions & Designators with WSO2 Identity Server 3.2.0

2011-04-21T19:43:00.012+05:30
WSO2 Identity Server 3.2.0 release provides two types of extensions to it's XACML PIP. [The release is not yet done - you can download a build from the latest trunk from here]

1.PIP Extensions

Once the PIP Extensions got registered with the system - the registered PIP Extension will be invoked for each and every XACML request the PDP receives and this happens before the request been evaluated.

PIP Extensions can be used to modify the incoming request as well as log relavent parameters.

2.PIP Desiginators.

Once the PIP Desiginators got registered with the system - the registered Desiginators will be invoked while a request been evaluated in the PDP and need to find out the value of an attribute which is supported by the Desiginator. The Desiginator will let the system know the attributes it supports at the time of registration.

To register a PIP Extension or a PIP Designator we need to copy the jars with those classes to [CARBON_HOME]\repository\components\lib and create a file called pip-config.xml inside [CARBON_HOME]\repository\conf with the following. Here I assume the PIP Extension class name is org.wso2.carbon.identity.sample.pip.SamplePIPExtension and PIP Designator class name is org.wso2.carbon.identity.sample.pip.SamplePIPDesignator.
<PIPConfig>
<AttributeDesignators>
<Designator class="org.wso2.carbon.identity.entitlement.pip.DefaultAttributeFinder" />
<Designator class="org.wso2.carbon.identity.sample.pip.SamplePIPDesignator" />
</AttributeDesignators>
<Extensions>
<Extension class="org.wso2.carbon.identity.sample.pip.SamplePIPExtension" />
</Extensions>
</PIPConfig>
Also, in the above file, make sure that you keep the entry <Designator class="org.wso2.carbon.identity.entitlement.pip.DefaultAttributeFinder" /> as it is, because it's the default PIP Designator which will by default talk to the underlying user store.

Now, let's see how to write PIP Extensions and Designators. You need to have org.wso2.carbon.identity.entitlement-3.2.0.jar and sun-xacml-2.0.1.wso2v1.jar in the classpath. [You can find those jars inside [IS_HOME]\repository\components\plugins
package org.wso2.carbon.identity.sample.pip;

import java.util.HashSet;
import java.util.Set;

import org.wso2.carbon.identity.entitlement.pip.PIPAttributeFinder;

public class SamplePIPDesignator implements PIPAttributeFinder {

@Override
public Set getAttributeValues(String subjectId, String resourceId,
String attributeId) throws Exception {
Set attributeValues = new HashSet();
attributeValues.add("myName");

System.out.println("SamplePIPDesignator Called");
System.out.println("SamplePIPDesignator SubjectId " + subjectId);
System.out.println("SamplePIPDesignator AttributeId " + attributeId);
System.out.println("SamplePIPDesignator Resource Id " + resourceId);

return attributeValues;
}

@Override
public Set getSupportedAttributes() {
Set attributes = new HashSet();
attributes.add("http://wso2.org/sample/claims/name");
return attributes;
}

}
package org.wso2.carbon.identity.sample.pip;

import org.wso2.carbon.identity.entitlement.pip.PIPExtension;

import com.sun.xacml.ctx.RequestCtx;

public class SamplePIPExtension implements PIPExtension{

@Override
public void update(RequestCtx request) {
System.out.println("SamplePIPExtension Called");
}

}
Notes :

1. The latest WSO2 Identity Server is running with the embedded ApacheDS LDAP server. The default port is 10389. If you want to change it, open CARBON_HOME\repository\conf\carbon.xml and look for LDAPServerPort and change it.

2. When you create or import a XACML policy to the Identity Server - policy will be in Disabled state - you need to Enable it by clicking the Enable link against the policy in the policy list page.

Invoking WSO2 Carbon Admin Services with a JAX-WS Client

2011-03-09T22:02:00.002+05:30
Any functionality available to you via WSO2 Carbon management console can also be invoked via a web service call.

In other word all these management related functionalities are exposed via web services.

To access these web services - also known as admin services, you need to be an authenticated user and also need to have the required set of permissions.

Following client demonstrates how you can create an authenticated session with WSO2 Carbon and then invoke an admin service with a JAX-WS client.
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.xml.namespace.QName;
import javax.xml.soap.MessageFactory;
import javax.xml.soap.SOAPBody;
import javax.xml.soap.SOAPConstants;
import javax.xml.soap.SOAPElement;
import javax.xml.soap.SOAPEnvelope;
import javax.xml.soap.SOAPMessage;
import javax.xml.soap.SOAPPart;
import javax.xml.ws.BindingProvider;
import javax.xml.ws.Dispatch;
import javax.xml.ws.Service;
import javax.xml.ws.handler.MessageContext;
import javax.xml.ws.soap.SOAPBinding;

public class AdminServiceClient {

private final static String AUTH_ADMIN_EPR = "https://localhost:9443/services/AuthenticationAdmin";
private final static String USER_ADMIN_EPR = "https://localhost:9443/services/UserAdmin";

/**
* @param args
*/
public static void main(String[] args) {

try {
QName serviceName = null;
QName portName = null;
Service service = null;
Dispatch<SOAPMessage> dispatch = null;
BindingProvider provider = null;
SOAPElement operation = null;
Map<String, Object> headers = null;
Map<String, List<String>> reqHeaders = null;
List<String> cookieList = null;
SOAPMessage response = null;
SOAPMessage request = null;
SOAPPart part = null;
SOAPEnvelope env = null;
SOAPBody body = null;
SOAPElement user = null;

serviceName = new QName("http://mgt.user.carbon.wso2.org", "UserAdmin");
portName = new QName("http://mgt.user.carbon.wso2.org", "UserAdminHttpsSoap11Endpoint");

service = Service.create(serviceName);
service.addPort(portName, SOAPBinding.SOAP11HTTP_BINDING, USER_ADMIN_EPR);

dispatch = service.createDispatch(portName, SOAPMessage.class, Service.Mode.MESSAGE);
provider = (BindingProvider) dispatch;

MessageFactory mf = MessageFactory.newInstance(SOAPConstants.SOAP_1_1_PROTOCOL);

request = mf.createMessage();
part = request.getSOAPPart();
env = part.getEnvelope();
body = env.getBody();

// We are going to get all the roles belong to the user "admin"
operation = body.addChildElement("getRolesOfUser", "ns",
"http://mgt.user.carbon.wso2.org");

user = operation.addChildElement("userName");
user.addTextNode("admin");

request.saveChanges();

// We can't just invoke the above method - since it belongs to an admin service. First
// we need to authenticate with AuthenticationAdmin and get the authenticated cookie.
// Then we need to add that cookie to the HTTP header of the request.
headers = provider.getRequestContext();
reqHeaders = (Map) headers.get(MessageContext.HTTP_REQUEST_HEADERS);

if (reqHeaders == null) {
reqHeaders = new HashMap<String, List<String>>();
}

cookieList = new ArrayList<String>();

// Let's authenticate as admin/admin and get the cookie.
cookieList.add(getCookie("admin", "admin"));

// Need to set this http header as Cookie
reqHeaders.put("Cookie", cookieList);

headers.put(MessageContext.HTTP_REQUEST_HEADERS, reqHeaders);
response = dispatch.invoke(request);

System.out.println(response.getSOAPBody().getFirstChild().getTextContent());

} catch (Exception e) {
e.printStackTrace();
}
}

private static String getCookie(String userName, String password) throws Exception {

QName serviceName = null;
QName portName = null;
Service service = null;
Dispatch<SOAPMessage> dispatch = null;
BindingProvider provider = null;
SOAPElement operation = null;
SOAPMessage response = null;
SOAPMessage request = null;
SOAPPart part = null;
SOAPEnvelope env = null;
SOAPBody body = null;
SOAPElement user = null;
SOAPElement pwd = null;

SOAPElement remoteAddr = null;

serviceName = new QName("http://authentication.services.core.carbon.wso2.org",
"AuthenticationAdmin");
portName = new QName("http://authentication.services.core.carbon.wso2.org",
"AuthenticationAdminHttpsSoap11Endpoint");

service = Service.create(serviceName);
service.addPort(portName, SOAPBinding.SOAP11HTTP_BINDING, AUTH_ADMIN_EPR);

dispatch = service.createDispatch(portName, SOAPMessage.class, Service.Mode.MESSAGE);

provider = (BindingProvider) dispatch;

MessageFactory mf = MessageFactory.newInstance(SOAPConstants.SOAP_1_1_PROTOCOL);

request = mf.createMessage();
part = request.getSOAPPart();

env = part.getEnvelope();
body = env.getBody();

operation = body.addChildElement("login", "ns",
"http://authentication.services.core.carbon.wso2.org");

user = operation.addChildElement("username");
user.addTextNode(userName);

pwd = operation.addChildElement("password");
pwd.addTextNode(password);

remoteAddr = operation.addChildElement("remoteAddress");
remoteAddr.addTextNode("wso2.org");

request.saveChanges();

response = dispatch.invoke(request);

if ("true".equals(response.getSOAPBody().getFirstChild().getTextContent())) {
List cookieList = null;
Map respHeaders = null;
Map<String, Object> headers = null;

headers = provider.getResponseContext();
respHeaders = (Map) headers.get(MessageContext.HTTP_RESPONSE_HEADERS);
// This is the JSESSIONID cookie.
cookieList = (List) respHeaders.get("Set-cookie");
return (String) cookieList.get(0);
} else {
return null;
}

}
}

Mac OS X Terminal Tips

2011-02-26T13:22:00.026+05:30

1. Go to beginning of the current line
Ctrl + A

2. Go to the end of the current line
Ctrl + E

3. Copy the current path
$ pwd | pbcopy

4. Clear the screen [same as clear]
Ctrl + L

5. Display all the environment variables
$ env

6. Deleting from current position to the end of the line
Ctrl + K

7. Deleting from current position to the beginning of the line
Ctrl + U

8. Deleting the first word before current position
Ctrl + W

9. Move the cursor a letter back from the current position
Ctrl + B

10. Move the cursor a letter forward from the current position
Ctrl + F

11. Open current location in Finder window
$ open .

12. Open a file with unknown extension with the default editor
$ open -t file.ext

13. Watch a particular file to see who's opening it
sudo opensnoop -f PathToTheFile

14. Text-to-speech
say "HI"

15. Runs the last command again !!

16. Hold option and click a position in the current line to move your cursor to that position.

17. List all possible commands Hit and hold ESC

Enabling secured browsing with Facebook

2011-02-20T09:34:00.004+05:30
Did you know there is an option in Facebook to enable secured browsing..?

Go to Account --> Account Settings --> Account Security and enable HTTPS browsing for your account as shown below.

I am bit surprised though why this isn't enabled by default.

There were many incidents reported where the Facebook sessions were hijacked - using Firesheep - a Firefox add-on.

11 GPG Commands One Should NEVER Forget

2011-02-16T07:48:00.010+05:30
GnuPG is the GNU project's complete and free implementation of the OpenPGP standard as defined by RFC4880 . GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories.

1. Create GPG Keys
$ gpg --gen-key
2. List the available keys in your keyring
$ gpg --list-keys
3. Exporting the public key - by user id
$ gpg --armor --export <uid>

Example :
$ gpg --armor --export prabath@wso2.com
4. Importing a public key of a trusted user to your keyring
$ gpg --import wso2.gpg
5. Encrypting a document - you need to import the public key corresponding to the uid-of-recipient first in to your keyring as per step - 4.
$ gpg --output <output-file> --encrypt --recipient <uid-of-recipient> <input-file>

Example :
$ gpg --output test.txt.gpg --encrypt --recipient prabath@wso2.com test.txt
6. Decrypting
$ gpg --output <output-file> --decrypt <input-file>

Example :
$ gpg --output text.txt --decrypt test.txt.gpg
7. Signing a document [detached signature]
$ gpg --armor --output <signature> --detach-sig <file-to-sign>
8. Verifying a signature [detached signature] - you need to have the public key of the person who signed it in your keyring - see step-4.
$ gpg --verify <signature> <original-file>
9. Exporting private keys
$ gpg --armor --output <key-file-name> --export-secret-keys <uid>

Example :
$ gpg --armor --output prabath.asc --export-secret-keys prabath@wso2.com
10. Uploading your public key to a key server.
$ gpg --keyserver certserver.pgp.com --send-key <uid>
11. Download a key from a key server.
$ gpg --keyserver certserver.pgp.com --recv-key <key_id>

WSO2 ESB Property Mediator - Different Scopes

2011-02-14T18:11:00.002+05:30
Properties are name value pairs. Properties are a way to convey information across different processing units. For example user may need to set a transport property from the message mediation. Or user may need to remove a property which is set by the transport. This mediator sets or removes properties for a particular message.

Property mediator has no direct impact on the message but rather on the message context flowing through Synapse. The properties set on a message can be later retrieved through the synapse:get-property(prop-name) XPath extension function. If a scope is specified for a property, the property could be set as a transport header property or an (underlying) Axis2 message context property, or as a Axis2 client option. If a scope is not specified, it will default to the Synapse message context scope. Using the property element with action specified as "remove" you can remove any existing message context properties.

The above extracted from the WSO2 ESB documentation...

This blog post focuses on different types of scopes available while setting properties.

1. Default - or the Synapse
Once you set a property under this scope - the value of it will be available through out both the in/out sequences.

To access this property inside the mediate() method of a mediator...
public boolean mediate(org.apache.synapse.MessageContext mc) {
// Available in both in-sequence and out-sequenc
String propValue = (String) mc.getProperty("PropName");
System.out.println("SCOPE_SYNAPSE : " + propValue);
return true;
}
2. Axis2
Once you set a property under this scope - the value of it will be available only through out the the sequence it's been set. If you set the Property mediator to the in-sequence, you cannot access it in the out-sequence.To access this property inside the mediate() method of a mediator...
public boolean mediate(org.apache.synapse.MessageContext mc) {
org.apache.axis2.context.MessageContext axis2MsgContext;
axis2MsgContext = ((Axis2MessageContext) mc).getAxis2MessageContext();

// Available only in the sequence the property is defined.
String propValue = (String) axis2MsgContext.getProperty("PropName");
System.out.println("SCOPE_AXIS2 : " + propValue);
return true;
}
3. Axis2-Client
This is similar to Synapse scope. The difference is - you can access it in following two ways..
public boolean mediate(org.apache.synapse.MessageContext mc) {
org.apache.axis2.context.MessageContext axis2MsgContext;
axis2MsgContext = ((Axis2MessageContext) mc).getAxis2MessageContext();
String propValue = (String) axis2MsgContext.getProperty("PropName");
System.out.println("SCOPE_AXIS2_CLIENT - 1 : " + propValue);

propValue = (String) axis2MsgContext.getOptions().getProperty("PropName");
System.out.println("SCOPE_AXIS2_CLIENT - 2: " + propValue);
return true;
}
4. Transport
Once you set a property under this scope - it will be added to the transport header of the out going message from the ESB.

Invoking A Secured Web Service With soapUI

2011-02-14T00:26:00.002+05:30
Thilina has written a very nice guide on the $subject Available here...

Accessing the HTTP method within a WSO2 ESB Mediator

2011-02-13T23:28:00.001+05:30
I couldn't find this in the ESB property documentation - so thought of keeping a note here.

Also - there is a chance that you can confuse the constant "HTTP_METHOD" with org.apache.axis2.transport.http.HTTPConstants.HTTP_METHOD - which internally refers to ""HTTP_METHOD_OBJECT""
public boolean mediate(org.apache.synapse.MessageContext synCtx) {
org.apache.synapse.core.axis2.Axis2MessageContext.Axis2MessageContext axis2Msgcontext = null;
org.apache.axis2.context.MessageContext msgContext = null;
axis2Msgcontext = (Axis2MessageContext) synCtx;
msgContext = axis2Msgcontext.getAxis2MessageContext();
String httpMethod = (String) msgContext.getProperty("HTTP_METHOD");
}

RPC with Java

2011-02-12T10:05:00.047+05:30
The goal of RPC in general is make distributed programming as easy as possible by creating the illusion that an exchange of data over the network that results in some processing (on another machine than the one the application is running on) is nothing more than a special kind of procedure call — one that has the special attribute of being “remote”.

Stating the obvious, there is a clear separation of roles in this scenario: the application invoking the procedure (the caller) is called the client, the one executing the procedure is the server. (In more advanced applications, a single program may assume both roles during the course of its execution.)

Unsurprisingly, RPC is the foundation of client/server computing. While RPC started out as a way to provide a transparent programming experience for traditional, procedural models, it was quickly followed by technologies that aimed to do the same for object-oriented programming. Examples include DCOM, CORBA, and RMI.

The first popular RPC solution was introduced by Sun (Sun RPC, later called ONC RPC) together with NFS, the Network File System. It featured all the important parts of more modern incarnations: An interface description with an associated stub/skeleton generator, marshaling, even a (albeit very simple) registry (portmap).

The other important RPC standard is DCE RPC, which is also used as the foundation of Microsoft’s DCOM.

The Sun RPC compiler is called rpcgen. As input, it takes a list of remote procedures (interfaces) defined in an interface definition language (IDL).

The output from rpcgen is a set of files that include...

1. Server code: Main function that sets up a socket, registers the port with a name server, listens for and accepts connections, receives messages, unmarshals parameters, calls the user-written server function, marshals the return value, and sends back a network message.

2. Client stub: The code with the interface of the remote function that marshals parameters, sends the message to the server, and unmarshals the return value.

3. Header: Contains definitions of symbols used by client and server as well as function prototypes

4. Data conversion functions: A separate file may be generated if special functions need to be called to convert between local data types and their marshaled forms.

The rpcgen tool generates code in C - from a given IDL.

Netbula JRPC is a complete port of the C version of ONC RPC to the Java(tm) platform - which generates code in JAVA. In this blog post we'll be using Netbula JRPC.

Also Distinct ONC RPC/XDR for Java - is another vendor who provides an ONC RPC toolkit in java.

Let's first have a look at how a sample IDL file looks like.
type definitions

program identifier {
version version_id {
procedure list
} = value;
} = value;
type definitions block is used to define structs - for example,
struct person {
string name<>;
int age;
};
Then the program block - a given program block can have different versions of the same interface - and program has a program number to identify it uniquely. In the following example, the program number is 1234567.
program msgserv {
.................
} = 1234567;
Now let's have a look at the version block. As I mentioned before there can be multiple version blocks inside a given program and each version is identified by the version number. In the following example - the version number is - 1.
program msgserv {
version MSGSERV_V1 {
....................
}= 1;
} = 1234567;
Next the procedure list. Inside a one version - there can be set of procedures defined. And there also each procedure is identified with a unique number. In the following example sendmsg() is identified by number - 2 and addperson() is identified by number - 3.
program msgserv {
version MSGSERV_V1 {
string sendmsg(string)=2;
void addperson(person)=3;
}= 1;
} = 1234567;
RPC Call Message
Each remote procedure call message contains the following unsigned integer fields to uniquely identify the remote procedure.
- Program number
- Program version number
- Procedure number

RPC Reply Message
The RPC protocol for a reply message varies depending on whether the call message is accepted or rejected by the network server. The reply message to a request contains information to distinguish the following conditions.
- RPC executed the call message successfully.
- The remote implementation of RPC is not protocol version 2. The lowest and highest supported RPC version numbers are returned.
- The remote program is not available on the remote system.
- The remote program does not support the requested version number. The lowest and highest supported remote program version numbers are returned.
- The requested procedure number does not exist. This is usually a caller-side protocol or programming error.

Let's get our hands dirty.. Following is the complete IDL of our example used here - which is in the file msg.x.
struct person {
string name<>;
int age;
};

program msgserv {
version MSGSERV_V1 {
string sendmsg(string)=2;
void addperson(person)=3;
}= 1;
} = 1234567;
Now, you need to download Netbula JRPC from here. You can find the jrpcgen tool inside the bin folder.

Let's use jrpcgen to generate Java code.
$ jrpcgen msg.x
This generates four files.

1. msgserv.java : The RPC program interface definition, including constant definition such as program number.

2. msgserv_cln.java : The client stub class. This class implements the RPC interface defined above. An RPC client program instantiate an instance of this class and call its methods (remote call).

3. msgserv_svcb.java : The RPC service. This class inherits the RPC interface and is abstract, the programmer needs to extend this class and supply the implmentation for the interface.

4. person.java : The corresponding Java file for the struct person.

Compile all four java files - make sure you have orpc.jar in the classpath. You can find orpc.jar inside the lib directory of Netbula distribution you downloaded.
$ javac msgserv.java person.java msgserv_cln.java msgserv_svcb.java -classpath orpc.dev\lib\orpc.jar
Next let's write the actual service and start it. Following is the code for it - msgsvc.java.
import netbula.ORPC.*;

public class msgsvc extends msgserv_svcb {

//implement the server function,
//let's just echo the msg back
public String sendmsg(String msg) {
System.out.println("got msg from client "+ msg);
return msg;
}

public void addperson(person psn) {
System.out.println("got msg from client");
}

//main function runs the server
public static void main(String srgv[]) {

//let's run the server using the run() method in Svc
//For more flexibility, one could use the TCPServer and UDPServer directly

new Thread(new PortMapper()).start();

try {
new msgsvc().run();
} catch(netbula.ORPC.rpc_err ex){
System.out.println("error occured");
}

}

}
class PortMapper implements Runnable {

@Override
public void run() {

try {
new Pmapsvc().run();
} catch (rpc_err e1) {
}
}
}
Now compile and start the server - msgsvc.java.
$ javac msgsvc.java -classpath .;orpc.dev\lib\orpc.jar
$ java msgsvc -classpath .;orpc.dev\lib\orpc.jar
Next the client... Following is the code for client.
import netbula.ORPC.*;

import java.net.*;

public class ClientTest {

public ClientTest () {}

static public void main(String args[]) {

try {

msgserv_cln cl = new msgserv_cln(args[0], "udp");
String msg = "hello world\n";

System.out.println("sending.. ");

for(int i=0; i<5; i++){
String reply = cl.sendmsg(msg);
System.out.println("got " + reply +"\n");
}
}catch (rpc_err e) {
System.out.println("rpc: " + e.toString());
}
}
}
Here, we constructed the client which connects to the server on host args[0] with UDP protocol, send a message, and print out the reply.
$ javac ClientTest.java -classpath .;orpc.dev\lib\orpc.jar
$ java ClientTest localhost -classpath .;orpc.dev\lib\orpc.jar
If you get here - means your sample works fine.. :-) Let's get in to the internals.

You may recall - that I mentioned jrpcgen produces four java classes. One of them is the interface, msgserv.java - which is been implemented by both the client and server side stubs.

Let's have a look at this interface.
public interface msgserv{

public static final int _def_pno = 1234567;
public static final int _def_vno = 1;

public static final int _sendmsg_proc = 2;
public static final int _addperson_proc = 3;

public String sendmsg(String in_arg) throws netbula.ORPC.rpc_err;
public void addperson(person in_arg) throws netbula.ORPC.rpc_err;
}
Can you notice that this defined four constants. _def_pno is the program number. _def_vno version number of the interface. Other two are the numbers corresponding to each procedure defined in the IDL.

Now let's have a look at the constructor of the client side stub, instantiated by our ClientTest.java above.
/**
Construct an RPC client object connected to a server
on the specified host with the specified protocol

@param host server hostname, or URL of the RPC proxy if http is used
@param proto protocol, can be "tcp", "udp" or "http"
*/
public msgserv_cln(String host, String proto) throws rpc_err {
super(host, msgserv._def_pno, msgserv._def_vno, proto);
}
See here in this constructor it passes the program number[_def_pno] and the version number[_def_vno] to construct the instance. So - this particular instance is created for a given version of the given program.

Now you got a very valid question. What if we have multiple versions inside the same program. How does this constructor look like. Well.. in case we have multiple versions - then for each version separate client/server stubs as well as an interface will be generated.

Similarly if you look at the sendmessage() method of client side stub, you will find out - the procedure number is used to invoke the method.

The above emphasizes on the value of having program number, version number and procedure numbers in RPC. Still not happy? Then let's have a look at the server side stub.
public XDT proc_call (int proc, XDR inXDR) throws XDRError {
switch(proc) {
case 0: return new XDTvoid();

case 2:
String _out_arg2;
try {
XDTString _in_arg = new XDTString();
_in_arg.xdr(inXDR);
_out_arg2 = this.sendmsg(_in_arg.value);
} catch (XDRError e) {
throw e;
}
return new XDTString(_out_arg2);

case 3:
try {
person _in_arg = new person();
_in_arg.xdr(inXDR);
this.addperson(_in_arg);
} catch (XDRError e) {
throw e;
}
return new XDTvoid();

default: return null;
}
}
Here, this the method invoked at the server side when a service method been invoked from the client end.

Here you will see - based on the procedure number, procedure been invoked.

References :

[1]: http://www.innoq.com/blog/st/2005/05/18/rpcstyle_web_services.html
[2]: http://netbula.com/javarpc/msgsamp.html
[3]: http://www.javvin.com/protocol/rfc1831.pdf : RPC: Remote Procedure Call Protocol Specification Version 2 (ONC version)
[4]: http://www.javvin.com/protocol/rfc1057.pdf : RPC: Remote Procedure Call Protocol Specification Version 2 (Sun version)

Adding custom HTTP headers via Axis2 Client

2011-02-10T11:50:00.004+05:30
This post explains how to add custom HTTP headers to a web service request initiated from an Axis2 client.

You may also have a look at this blog post by Keith, which explains how to add custom HTTP header to a response message from Axis2 service end.
// Create an instance of org.apache.axis2.client.ServiceClient
ServiceClient client = ...

// Create an instance of org.apache.axis2.client.Options
Options options = new Options();

List list = new ArrayList();

// Create an instance of org.apache.commons.httpclient.Header
Header header = new Header();

// Http header. Name : user, Value : admin
header.setName("user");
header.setValue("admin");

list.add(header);
options.setProperty(org.apache.axis2.transport.http.HTTPConstants.HTTP_HEADERS, list);

client.setOptions(options);

Securing RESTful Services

2011-02-05T13:48:00.001+05:30

Video recording available here...

[WSO2 ESB] Invoking a Web Service via HTTPS from a Proxy Service

2011-02-05T11:54:00.008+05:30
1. Get the public certificate of the Web Service deployed over HTTPS

2. Import the certificate from [1] to [ESB_HOM]/resources/security/client_truststore.jks

:\>keytool import public_cert.crt -alias myservice -keystore client_truststore.jks

The default password is wso2carbon. You can put any name to alias [e.g. myservice] and need to replace public_cert.crt with name of the certificate you have from [1].

3.You may be using an IP address as the web service end point or the CN of the certificate issued for the end point may not match its server url. This could cause a host name verification error.

To overcome that, find the following in [ESB_HOME]/repository/conf/axis2.xml ..

<parameter name="HostnameVerifier">DefaultAndLocalhost</parameter>

uncomment it and change it to the following...

<parameter name="HostnameVerifier">AllowAll</parameter>

4. If the Web Service or it's WSLD - or the both enabled for mutual authentication - you need export the public certificate of WSO2 ESB out and import it to the trust store of the Web Service.

To export out the ESB public certificate you can use the following.

:\>keytool export -file esb_public_cert.crt -alias wso2carbon -keystore wso2carbon.jks

You can find wso2carbon.jks at [ESB_HOM]/resources/security/wso2carbon.jks and it default password is wso2carbon.

That's it..

Java Class Loading

2011-02-05T01:12:00.002+05:30
Class loading is widely viewed as one of the darkest arts in Java development. In this session, Jason Greene will provide insight into the how and why of Java SE, Java EE, JBoss Application Server, JBoss Microcontainer, and OSGi class loading. He will offer historical perspective by beginning with JDK internals and progress to the modern, modular class loader models in use today. In addition, Jason will cover common pitfalls and methodologies to avoid them.

The Zen of Class Loading from JBoss Developer on Vimeo.

[Blogging] 10 Tips to get 1000 Hits per day

2011-02-03T22:33:00.006+05:30

1. Pick the most catching subject

2. Make the content short and sweet

- Essay like content doesn't help. Make the content as short as possible.
- One image worths thousand words - use images whenever appropriate.
- Use syntax-highlighters whenever you publish code.
- Use spacing/gaps as necessary - to make the blog posts more readable
- Use proper tags to tag your blog posts.
- Don't make the blog looks crowded with too many widgets/gadgets.

3. Keep the blog updated regularly

- Blog regularly and make sure you answer readers' comments
- Frequent updates helps to improve Google page rank

4. No anonymous blogging

- Always blog with a human name. That will give the readers' the feeling of being real.
- Post your email address or a way to contact you directly, in the blog

5. Publish on DZone

- DZone is a technology publishing company that produces valuable content for software architects and developers worldwide.
- It has a considerable amount of user base, highly focused on technology related topics.
- Do not publish your links on Weekends.
- Tag your DZone link properly
- Share the DZone link [via DZone]
- Make the DZone link description meaningful/attractive and readable.
- Participate in discussions via comments to the link

6. Publish on reddit

- Reddit is a social news website which has wide variety of topics.
- Pick the most appropriate topic for your link.
- Reddit has a huge user base compared to DZone.

7. Tweet

- Tweet about your blog post.
- Use hash-tags appropriately.
- Publish first in DZone and then Tweet the DZone link.
- Use catching words to describe what you have in the blog post - it need to not be the title always.

8. Share in Facebook

- Post a link to your blog post in Facebook
- Publish first in DZone and then share the DZone link

9. Subscribe to blog aggregators

- Subscribe to appropriate blog aggregators
- Don't publish the entire blog post to feeds. Blogger has an option to limit number of words.

10. Use SEO best practices to improve your Google Page Rank

WSO2 Application Server 4.0

2011-02-01T06:43:00.002+05:30

Building an Enterprise SOA Security Gateway

2011-01-31T13:02:00.014+05:30
I was looking for a 'formal' definition of 'SOA Security Gateway'. Failing to find such [yes, not even in Wikipedia] let's try to build one..

Message Interceptor Gateway pattern is the one that directly comes in to my mind.. We have implemented this at many customers with WSO2 product stack.. ESB, IS, GReg and WSAS/DSS.

This pattern provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages. The security tasks include creating, modifying, and administering security policies for sending and receiving SOAP messages. It helps to apply transport-level and message-level security mechanisms required for securely communicating with a Web services endpoint.

Isn't this the functionality we are looking from a Security Gateway..?

BTW, if you are building a Security Gateway, you can't ignore OWASP XML Security Gateway Evaluation Criteria project.

The OWASP XML Security Gateway Evaluation Criteria Project (XSGEC) defines an open standard for evaluating XML Security Gateways, such as those used to protect and provide security services for Web services applications.

This project categorizes the evaluation criteria in to 9 sections.

1. Authentication
2. Authorization
3. Audit Logging
4. Deployment Architecture
5. Content Validation
6. Management & Metrics
7. Transformation
8. Tools
9. Performance

The authentication section describes the support at the service level and message level for inbound and outbound communication to the Security Gateway.

In bound traffic can be protected with any of the following security techniques.

- Mutual SSL
- HTTP Basic Authentication
- HTTP Digest Authentication
- WS-Security Username Token Authentication
- WS-Security X.509 Certificate Based Authentication
- WS-Security: Kerberos Token
- SAML Authentication assertion
- Validation against Active Directory
- Dereference Active Directory Federation Service

Outbound traffic can be protected with following techniques..

- Mutual SSL
- HTTP Basic Authentication
- HTTP Digest Authentication
- WS-Security Username Token
- WS-Security X.509 Certificate
- WS-Security: Kerberos Token
- SAML Authentication assertion
- WS-Federation assertion

Looking at the Authorization section - it covers,

- XACML
- SAML
- LDAP

Being part of the WSO2 Security team for years now, it's so natural to think, how we meet these criteria with WSO2 Product Stack..?

In fact we do already... Only thing we lack is the full support for WS-Federation. Even a set of students from University of Moratuwa - currently working on adding WS-Federation support for Rampart - which is the security module of Axis2.

To be more precise - we have already done this at some of our customers.

Let me briefly share some of my experience with a customer who is highly concerned about security.

They had the backend services already implemented with WCF and protected with Integrated Windows Authentication[IWA] - hosted in IIS.

They have three types of clients who need access to the BE services.

1. Windows Client
2. C++ client running on a Linux box
3. Third party client - out side their domain

Windows client doesn't have any issues in accessing the BE services - with IWA.

C++ client had some technical challenges. It is already developed and only way it supports securing the communication channel to the BE services is through BasicAuthentication.

Third party client can be developed on any platform. The challenge is - we do not know how to authenticate users who are coming from a different domain - and they also need to integrate with internal windows authentication.

Apart from this - we also need to authorize each and every user.

Sounds interesting ? ;)

Let me summarize the requirements..

1. Windows Client -- [Authentication with Kerberos] -- [Authorization] -- > BE Services

2. C++ client -- [Authentication with BasicAuthentication] -- [Authorization] -- [Authentication with Kerberos] --> BE Services

3. Third Party client -- [Authentication?] -- [Authorization?] -- [Authentication with Kerberos] -- > BE Services

We need define a method to authenticate third party users - who we do not have access to the credential store -- that is WS-Trust

We need to do a credential conversion from BasicAuthentication to Kerberos and WS-Trust to Kerberos.

Apart from this we need to have an authorization scheme as well.

Let me explain our solution.

We decided to have WSO2 ESB - acting as a security gateway - implementing the message interceptor gateway pattern.

Also - we decided not to propagate end user credentials to the BE services. It's up to the ESB to authenticate and authorize users and occupy the trusted sub system pattern to authenticate to the BE with Kerberos.

1. Windows Client -- [Authentication with Kerberos] --> ESB -- [Authorization with XACML] -- [Authenticating with Kerberos] -- > BE Services

2. C++ client -- [Authentication with BasicAuthentication] --> ESB -- [Authorization with XACML] -- [Authentication with Kerberos] --> BE Services

3. Third Party client -- [Authentication with WS-Trust] --> ESB [Authorization with XACML] -- [Authentication with Kerberos] -- > BE Services

The above gives us a unified authentication and authorization scheme across three different clients.

It's true that with this pattern we do not pass user credentials to the BE services. But, still we need to send the user name corresponding to the request to the BE. In that case we wrote a mediator to extract the user name from the incoming request and attach it to the out going message form the ESB to the BE services.

Okay.. one last question.. It's clear that we can define an authorization scheme for internal users - based on their roles.. But.. how do we authorize third party users..?

All the requests [based on WS-trust] are signed by the corresponding STS. So - with the signature - we can identify to who a particular user belongs to. Internally we define roles for each and every partner and once via the signature we identified the partner, we can easily figure out the mapped role that particular user belongs to. The XACML policy authorizes the user against this role.

I guess that's pretty much the solution to that specific problem - although in my description I do not cover how to govern both the security policies and XACML policies - which should also be part of a Security Gateway Solution.

If you are further interested in reading about more features that you should look into, while building a Security Gateway - it's highly recommended that you go through Security Gateway Buyer's Guide.

SOAP vs REST | XML vs JSON

2011-01-22T11:32:00.001+05:30

View more presentations from Robert MacLean.

Catch who removed you from Facebook...!

2011-01-21T01:13:00.005+05:30
Facebook doesn't send notifications upon unfriending.. although it does when somebody added you.

This blog post explains how to catch people who remove you from Facebook friend list.

Before running the following java program, you need to do the following steps..

0. Go to http://www.facebook.com/#!/pages/Facebook-Developer/7213347185 and LIKE that page.

1. Go to http://www.facebook.com/developers and click on "Set Up New App"

2. Once done with [1] - go to the link http://developers.facebook.com/docs/reference/rest/auth.createtoken and select your application from the "Test Console" and click on the link which looks like https://api.facebook.com/method/auth.createToken?
access_token=...

3. Now a new browser window will be opened up and from the Url - copy the access_token - which is in the query string. Make sure you properly copy the access_token value only - don't mess up with the other query string parameters present in the same Url.

4. Replace the value of the constant ACCESS_TOKEN in code below with the one you got from [3].

5. Download the RestFB jar from here and add it to the classpath of the java program.

6. That's it and whenever you run the following program you will see the friends you made and lost from your previous run.
package samples.fb.app;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.List;
import java.util.Map.Entry;

import com.restfb.Connection;
import com.restfb.DefaultFacebookClient;
import com.restfb.FacebookClient;
import com.restfb.types.User;

public class FacebookTestClient {

private final static String ACCESS_TOKEN = "126895777dsd7843z4erer7C2.WfdfgQmjj376b_gfdfdf__.3600.1295557200-787236966%7CQ0166mXlhvmBoCXohUDVpfWrYAg";

public static void main(String[] args) {

FacebookClient facebookClient = new DefaultFacebookClient(ACCESS_TOKEN);
Connection<User> myFriends = facebookClient.fetchConnection("me/friends", User.class);

List<User> list = myFriends.getData();
Hashtable<String, String> newFriends = new Hashtable>String, String>();
Hashtable<String, String> oldFriends = loadOldFriends();

for (Iterator<User> iterator = list.iterator(); iterator.hasNext();) {
User friend = iterator.next();
newFriends.put(friend.getId(), friend.getName());

if (oldFriends != null) {
if (!oldFriends.containsKey(friend.getId())) {
System.out.println("You have a new friend today, " + friend.getName());
}
}
}

if (oldFriends != null) {
for (Iterator<Entry<String, String>> iterator = oldFriends.entrySet().iterator(); iterator
.hasNext();) {
Entry<String, String> friendEntry = iterator.next();
if (!newFriends.containsKey(friendEntry.getKey())) {
System.out.println("You lost a friend today, " + friendEntry.getValue());
}

}
}

saveFriends(newFriends);

}

private static void saveFriends(Hashtable<String, String> friends) {

try {
FileOutputStream fileOut = new FileOutputStream("friendlist.ser");
ObjectOutputStream out = new ObjectOutputStream(fileOut);
out.writeObject(friends);
out.close();
fileOut.close();
} catch (Exception e) {
e.printStackTrace();
}
}

private static Hashtable<String, String> loadOldFriends() {

Hashtable<String, String> friends = null;

try {
if (new File("friendlist.ser").exists()) {
FileInputStream fileIn = new FileInputStream("friendlist.ser");
ObjectInputStream in = new ObjectInputStream(fileIn);
friends = (Hashtable<String, String>) in.readObject();
in.close();
fileIn.close();
}
} catch (Exception e) {
e.printStackTrace();
}
return friends;
}
}

SSL stripping on OS X with SSLStrip

2011-01-06T04:27:00.003+05:30
SSLStrip tool provides a demonstration of the HTTPS stripping attacks - you can download it from here.

Then on OS X 10.6.5 with MacPorts we need to install following dependancies.

1. $ sudo port selfupdate

2. $ sudo port install py25-twisted-web2

3. $ sudo port install py25-socket-ssl

4. $ sudo port install py25-openssl

Now, run the following from the SSLStrip home directory.

$ sudo python sslstrip.py -l 9090 -w captured.log

This will start SSLStrip listening on port 9090 - and will write all captured traffic in to the captured.log

Now starts the interesting part.. We need to make the traffic from our target machine goes through SSLStrip. To do that first we need to make sure the traffic flows through our machine. That we can do by ARP poisoning target machine. My previous blog post explains how to do that. Once that is done - we need to forward all that incoming traffic to port where SSLStrip running.

Enable IP forwarding on MAC.

$ sudo sysctl -w net.inet.ip.forwarding=1
$ sudo sysctl -w net.inet.ip.fw.verbose=1

Now we need to add a rule to IPFW to redirect traffic to the port SSLStrip is running.

$ sudo ipfw add fwd 127.0.0.1,9090 log tcp from not me to any 80

History of cryptography and its early stages in Europe

2011-01-04T20:17:00.001+05:30
Very nice presentation from http://www.criptored.upm.es/intypedia

ARP poisoning with dsniff

2011-01-04T17:27:00.001+05:30
dsniff is a collection of tools for network auditing and penetration testing. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and macof facilitate the interception of network traffic normally unavailable to an attacker (e.g, due to layer-2 switching). sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI.

To install dsniff on MAC OS X - with MacPorts.

$ sudo port install dsniff

Now you need to find out two things,

1. IP address of the target machine - say 192.168.1.4
2. IP address of the Gateway - say 192.168.1.1

Let's start ARP poisoning from the attacker's machine - with arpspoof tool which comes with dsniff.

$ sudo arpspoof -i en1 -t 192.168.1.4 192.168.1.1

This will update target machine's ARP table with attacker's MAC address against the IP address of the gateway.

Now - start a tcpdump on the same interface from your machine - start viewing all the traffic going to and from the target machine.

$ sudo tcpdump -i en1

Writing a JAX-WS client to an Axis2 web service

2011-01-04T11:16:00.003+05:30
1. Deploying the Axis2 Service

Download and launch Apache Axis2 - it comes with a sample web service which is by default available at http://localhost:8080/axis2/services/Version - we will be using this as the service to write our JAX-WS client.

2. JAX-WS

The Java API for XML Web Services (JAX-WS) is a Java programming language API for creating web services. It is part of the Java EE platform from Sun Microsystems. Like the other Java EE APIs, JAX-WS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints.The Reference Implementation of JAX-WS is developed as an open source project and is part of project GlassFish.

3. Axis2 and JAX-WS

http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html

4. JAX-WS client

First we need to generate the Stub classes for the service we are going to invoke. This can be done using the wsimport tool. The tool is available at [JAVA_HOME]\bin distribution.
$ pwd
/Users/prabath/blog/jax-ws
$ wsimport -p org.wso2 http://localhost:8080/axis2/services/Version?wsdl
The above resulted with the following error.
[ERROR] A class/interface with the same name "wso2.Exception" is already in use. Use a class customization to resolve this conflict.
line 11 of http://localhost:8080/axis2/services/Version?wsdl
So I got to hand edit the wsdl and save it as wsdl.xml - and run wsimport against wsdl.xml
$ pwd
/Users/prabath/blog/jax-ws
$ wsimport -p org.wso2 wsdl.xml
$ jar -cvf version-stub.jar *
Following is the client code - and you need to have version-stub.jar, which was generated in the previous step.
package jax.ws.client;

import javax.xml.ws.WebServiceRef;

import org.wso2.Version;
import org.wso2.VersionPortType;

public class VersionClient {
@WebServiceRef(wsdlLocation = "http://localhost:8080/axis2/services/Version?wsdl")

public static void main(String[] args) {
try {
Version service = new Version();
VersionPortType port = service.getVersionHttpSoap11Endpoint();
String response = port.getVersion().getReturn().getValue();
System.out.println(response);
} catch (Exception e) {
e.printStackTrace();
}
}

}

Writing a JAX-RPC client to an Axis2 web service

2011-01-03T16:57:00.007+05:30
1. Deploying the Axis2 Service

Download and launch Apache Axis2 - it comes with a sample web service which is by default available at http://localhost:8080/axis2/services/Version - we will be using this as the service to write our JAX-RPC client.

2. JAX-RPC

JAX-RPC is intended to be a Java API to expose remote procedure calls that use XML to business applications and it facilitates the invocation of remote procedures using XML as the data format and SOAP as the data protocol. The overhead in developing JAX-RPC clients is minimal since the API it self abstracts and hides the low level SOAP semantics associated with RPC from applications.

3. Axis2 and JAX-RPC

Although Axis [version - 1] had support for JAX-RPC - Axis2 does not. Axis2 has the support for JAX-WS - JAX-WS 2.0 is the successor of JAX-RPC 1.1 - the Java API for XML-based Web services. If possible, JAX-WS should be used instead as it is based on the most recent industry standards.

4. JAX-RPC client

First we need to generate the Stub classes for the service we are going to invoke. This can be done using the wscompile tool. The tool is available with the GlassFish distribution.

wscompile tool needs a configuration file as an input - which dictates where to find the corresponding WSDL and the required package names for the stubs to be generated. Let's first create that config file, say version-config.xml
<configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
<wsdl location="http://localhost:8080/axis2/services/Version?wsdl" packageName="org.wso2"/>
</configuration>
Now lets generate the stubs with the wscompile tool.
$ pwd
/Users/prabath/blog/jax-rpc
$ sh ~/glassfishv3/glassfish/bin/wscompile -gen:client version-config.xml
$ jar -cvf version-stub.jar *
Following is the client code - and you need to have version-stub.jar, which was generated in the previous step and javaee.jar from [GLASSFISH_HOME]/glassfish/lib
package jax.rpc.client;

import javax.xml.rpc.Stub;

import org.wso2.VersionPortType_Stub;
import org.wso2.Version_Impl;

public class VersionClient {

public static void main(String[] args) {

try {
Stub stub = createProxy();
stub._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,
"http://localhost:8080/axis2/services/Version");
VersionPortType_Stub hello = (VersionPortType_Stub) stub;
System.out.println(hello.getVersion());
} catch (Exception ex) {
ex.printStackTrace();
}
}

private static Stub createProxy() {
return (Stub) new Version_Impl().getVersionHttpSoap11Endpoint();
}

}
5. JAX-RPC Vs JAX-WS

JAX-WS still supports SOAP 1.1 over HTTP 1.1, so interoperability will not be affected. The same messages can still flow across the wire.

JAX-WS still supports WSDL 1.1 so what you've learned about that specification is still useful.

What are the differences?

SOAP 1.2
JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.

XML/HTTP
The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.

WS-I's Basic Profiles
JAX-RPC supports WS-I's Basic Profile (BP) version 1.0. JAX-WS supports BP 1.1. (WS-I is the web services interoperability organization.)

New Java features
JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today's web services novices.

The data mapping model
JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.
JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas.

The interface mapping model
JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's; however:
JAX-WS's model makes use of new Java 5.0 features.
JAX-WS's model introduces asynchronous functionality.

The dynamic programming model
JAX-WS's dynamic client model is quite different from JAX-RPC's. Many of the changes acknowledge industry needs:
It introduces message-oriented functionality.
It introduces dynamic asynchronous functionality.
JAX-WS also adds a dynamic server model, which JAX-RPC does not have.

MTOM (Message Transmission Optimization Mechanism)
JAX-WS, via JAXB, adds support for MTOM, the new attachment specification. Microsoft never bought into the SOAP with Attachments specification; but it appears that everyone supports MTOM, so attachment interoperability should become a reality.

The handler model
The handler model has changed quite a bit from JAX-RPC to JAX-WS.
JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification

Reference : http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc.html

ERROR - ProxyService Error reading from wsdl URI

2010-12-28T10:32:00.001+05:30
$subject could be a common error for many new ESB users - so, thought of keeping a note here.

This could easily happen if you create a proxy service against the sample echo service which ships with WSO2 ESB - and WSDL was pointed with an URI - and the corresponding WSDL is unavailable at the time proxy service been deployed [i.e. When the ESB is restarted]

<publishWSDL uri="http://localhost:8280/services/echo?wsdl"/>

To recover from this error - you need to edit the file [ESB_HOME]/repository/conf/synapse-config/proxy-services/your_service_name.xml and add the following parameter..
<proxy name="test" transports="https http" startOnLoad="true" trace="disable">
..............
..................
<parameter name="enablePublishWSDLSafeMode">true</parameter>
</proxy>

Now restart the ESB and you will notice that this particular proxy service is not loaded - but the ESB starts fine.

To handle this issue in a more generic way - a fail-safe mode to be introduced in to the upcoming release of WSO2 ESB - further details here...

Enforcing JDBC clients to use SSL with MySQL Server

2010-12-27T21:42:00.003+05:30
1. First you need to enable SSL at both the server and the client as per my previous blog post.

2. There you would have noticed that - even though we enabled SSL at the server end - still the JDBC clients can connect with out using SSL.

3. To enforce SSL for the JDBC connection from the client end - we need to have REQUIRE SSL - in the GRANT statement for the MySQL user associated with the JDBC client.

e.g :

GRANT ALL ON regdb.* TO regadmin@localhost IDENTIFIED BY "regadmin" REQUIRE SSL;

4. Now regadmin user won't be able to connect to the regdb database without a JDBC connection over SSL.

Deploying WSO2 Carbon Server over Novell eDirectory

2010-12-27T05:27:00.000+05:30
Recently we did the $subject in a production deployment and thought of keeping a small note here.

I blogged about the $subject sometime back here - but that is no more applicable to Carbon 3.0.x products.

To deploy WSO2 Carbon Server over Novell eDirectory - you can follow the exact guidelines provided in this blog post - following is the only exception.

Instead of setting objectClass=person under UserNameListFilter property - set, objectClass=Person

Note : 'P' is in upper-case there.

Connecting WSO2 Carbon Server to a MySQL DB over a Secured Channel

2010-12-26T17:54:00.009+05:30
In my previous blog post I explain how to connect WSO2 Carbon Server to a MySQL database. Please make sure it works fine before going through this.

In this blog post I will only explain changes required to enable SSL.

SSL in MySQL Connector/J encrypts all data (other than the initial handshake) between the JDBC driver and the server. The performance penalty for enabling SSL is an increase in query processing time between 35% and 50%, depending on the size of the query, and the amount of data it returns.

1. Verify whether your MySQL distribution supports SSL. Use following command and make sure it doesn't result with an Error.
$ cd /usr/local/mysql

$ sudo ./bin/mysqld_safe --ssl
101226 13:50:26 mysqld_safe Logging to '/usr/local/mysql-5.1.51-osx10.6-x86_64/data/prabath-siriwardenas-MacBook-Pro.local.err'.
101226 13:50:26 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql-5.1.51-osx10.6-x86_64/data
2. Then login to the mysql and run the following query.
mysql> SHOW VARIABLES LIKE 'have_ssl';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_ssl | YES |
+---------------+-------+
1 row in set (0.00 sec)
3. If all works fine - then your MySQL distribution is enabled for SSL.

4. Now we need to set certificate to the MySQL Server. Here I am generating certificates with OpenSSL and copy them to /usr/local/mysql/ssl [If you don't see a directory 'ssl' - just create one there.]
$ pwd
/usr/local/mysql/ssl

$ openssl req -x509 -newkey rsa:1024 -keyout server-key.key -out server-cert.pem

$ cp server-cert.pem ca-cert.pem

$ openssl rsa -in server-key.key -out server-key.pem

5. Stop the running mysql server and start it as below.
$ cd /usr/local/mysql

$ sudo ./bin/mysqld_safe --ssl-ca=/usr/local/mysql/ssl/ca-cert.pem --ssl-cert=/usr/local/mysql/ssl/server-cert.pem --ssl-key=/usr/local/mysql/ssl/server-key.pem

101226 18:16:42 mysqld_safe Logging to '/usr/local/mysql-5.1.51-osx10.6-x86_64/data/prabath-siriwardenas-MacBook-Pro.local.err'.
101226 18:16:42 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql-5.1.51-osx10.6-x86_64/data
6. Once again login to the mysql and run the following query.
mysql> SHOW VARIABLES LIKE '%ssl%';
+---------------+--------------------------------------+
| Variable_name | Value |
+---------------+--------------------------------------+
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca | /usr/local/mysql/ssl/ca-cert.pem |
| ssl_capath | |
| ssl_cert | /usr/local/mysql/ssl/server-cert.pem |
| ssl_cipher | |
| ssl_key | /usr/local/mysql/ssl/server-key.pem |
+---------------+--------------------------------------+
7 rows in set (0.01 sec)
7. That's it we all need from the MySQL Server end.

8. Now you need to import the public certificate and the CA certificate of MySQL server to [CARBON_HOME]\resources\security\client-truststore.jks. But in this case since we use verifyServerCertificate=false in the JDBC connection url of the WSO2 Carbon Server - we can skip this step.

9. Now in both the user-mgt.xml and registry.xml we need to edit the ConnectionUrl and add useSSL=true, verifyServerCertificate=false and requireSSL=true.

jdbc:mysql://localhost:3306/regdb?verifyServerCertificate=false&useSSL=true&requireSSL=true

Deploying WSO2 Carbon Server over a secured LDAP [s] connection

2010-12-26T17:00:00.001+05:30
Please refer my previous blog post to see how to deploy WSO2 Carbon Server over a LDAP User Store.

I will highlight only the changes from there - when it comes to a secured LDAP connection.

1. Change the ConnectionURL and set ldaps instead of ldap and set the port correctly.

2. Import the LDAP server's SSL certificate in DER format to [CARBON_HOME]\resources\security\client-truststore.jks. If the certificate is not in DER format you can use OpenSSL to convert it to DER.

3. When starting the Carbon Server - start as following.

$ sh wso2server.sh -Djavax.net.ssl.trustStore=/[CARBON_HOME]/resources/security/client-truststore.jks -Djavax.net.ssl.trustStorePassword=wso2carbon

There replace [CARBON_HOME] with your absolute path to CARBON_HOME.

That's it.

Deploying WSO2 Carbon over an LDAP User Store

2010-12-26T16:35:00.007+05:30
Open up the [CARBON_HOME]\repository\conf\user-mgt.xml and replace it's content with the following.

ConnectionURL : Connection URL to the LDAP server
ConnectionName : Full qualified name of a user to access the LDAP server.
ConnectionPassword: Password of the ConnectionName. If you allow anonymous access keep this blank.
UserSearchBase : Where the system should find the users - ConnectionName should be within the UserSearchBase
UserNameListFilter: This is to narrow down the search. Set the objectClass properly.
UserNameAttribute : This should be attribute where the system will take as the user name for login.
ReadLDAPGroups : If true will read groups from the LDAP server.
GroupSearchBase : Where the system should find the groups.
GroupSearchFilter : This is to narrow down the search. Set the objectClass properly.
GroupNameAttribute: This should be attribute where the system will take as the group name.
AdminUser/UserName: This user will be treated as the initial admin of the system. Should be belonging to the UserSearchBase in LDAP. Keep the password of this user blank.
<UserManager>
<Realm>
<Configuration>
<AdminRole>admin</AdminRole>
<AdminUser>
<UserName>prabath</UserName>
<Password>XXXXXX</Password>
</AdminUser>
<EveryOneRoleName>everyone</EveryOneRoleName> 
<ReadOnly>true</ReadOnly>
<MaxUserNameListLength>500</MaxUserNameListLength>
<Property name="url">jdbc:h2:repository/database/WSO2CARBON_DB</Property>
<Property name="userName">wso2carbon</Property>
<Property name="password">wso2carbon</Property>
<Property name="driverName">org.h2.Driver</Property>
<Property name="maxActive">50</Property>
<Property name="maxWait">60000</Property>
<Property name="minIdle">5</Property>
</Configuration>
<UserStoreManager
class="org.wso2.carbon.user.core.ldap.LDAPUserStoreManager">
<Property name="ConnectionURL">ldap://localhost:10389</Property>
<Property name="ConnectionName">uid=admin,ou=system</Property>
<Property name="ConnectionPassword">secret</Property>
<Property name="UserSearchBase">ou=system</Property>
<Property name="UserNameListFilter">(objectClass=person)</Property>
<Property name="UserNameAttribute">uid</Property>
<Property name="ReadLDAPGroups">false</Property>
<Property name="GroupSearchBase">ou=system</Property>
<Property name="GroupSearchFilter">(objectClass=groupOfNames)</Property>
<Property name="GroupNameAttribute">cn</Property>
<Property name="MembershipAttribute">member</Property>
</UserStoreManager>
<AuthorizationManager
class="org.wso2.carbon.user.core.authorization.JDBCAuthorizationManager">
</AuthorizationManager>
</Realm>
</UserManager>

Deploying WSO2 Identity Server over MySQL

2010-12-26T16:20:00.000+05:30
My previous blog post explains setting up MySQL Server and related tools under Mac OS X.

Once you are done with setting up MySQL - login as a root and execute the following SQL. You can use MySQL Workbench for this.
create database regdb;

use regdb;

GRANT ALL ON regdb.* TO regadmin@localhost IDENTIFIED BY "regadmin"
Once that is done. Open up the [IDENTITY_SERVER_HOME]\repository\conf\registry.xml and add the following section under <wso2registry>.
<dbConfig name="mysql-db">
<url>jdbc:mysql://localhost:3306/regdb</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>60000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
Now, find <currentDBConfig> in registry.xml and set it to mysql-db.

That's it for the registry.

Now, we need to set User Manager database pointing to the MySQl DB.

Open up the [IDENTITY_SERVER_HOME]\repository\conf\user-mgt.xml and edit following settings.
<Configuration>
...
<Property name="url">jdbc:mysql://localhost:3306/regdb</Property>
<Property name="userName">regadmin</Property>
<Property name="password">regadmin</Property>
<Property name="driverName">com.mysql.jdbc.Driver</Property>
<Property name="maxActive">50</Property>
<Property name="maxWait">60000</Property>
<Property name="minIdle">5</Property>
</Configuration
Then you need to copy the MySQL DBC driver from http://dev.mysql.com/downloads/connector/j/5.1.html and Place it in the $IDENTITY_SERVER_HOME/repository/components/lib directory.

That's it - and start the identity server as sh bin/wso2server.sh -Dsetup

Installing MySQL Community Server and related tools in Apple Mac OS X

2010-12-26T15:10:00.003+05:30
1. Download MySQL for MAC OS X from here and install it.

2. To start the MySQL server
$ cd /usr/local/mysql

$ sudo ./bin/mysqld_safe
101226 13:50:26 mysqld_safe Logging to '/usr/local/mysql-5.1.51-osx10.6-x86_64/data/prabath-siriwardenas-MacBook-Pro.local.err'.
101226 13:50:26 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql-5.1.51-osx10.6-x86_64/data
mysqld_safe is the recommended way to start a mysqld server on Unix and NetWare. mysqld_safe adds some safety features such as restarting the server when an error occurs and logging runtime information to an error log file.

3.Now you can download MySQL GUI tools for Mac OS X from here.

4. Once MySQL GUI tools installed - you can click on MySQL Administrator and login as root with blank password - then go to Accounts and change the root password.

5. You can download MySQL Workbench for Mac OS X from here.

Reverting selected adds in SVN

2010-12-06T04:26:00.000+05:30
I've been used to the TortoiseSVN client for years now and it gave me everything I needed in a nice UI. Recently I moved to Mac OS X and now getting used to the SVN command line client.

I by mistake today did an svn add from the root folder - which added all .java as well as .class files.

I could do an svn revert easily, but that will revert the changes I did for existing files as well - which I do not want to happen.

So - following is the one I came up with and works really handy - and thought of sharing.

From the root folder...
$ find . -name '*.class' | xargs svn revert

Shell script for bulk signing

2010-12-05T12:02:00.001+05:30
We at WSO2 most of the time release many products at once. With the binary distribution + source distribution + docs - amounts to a large number distributions.

And signing and generating MD5 and SHA1 for all those is a painful task.

Following script makes it easy - copy all the distributions to a single directory and copy the following script to the same directory as sign.sh and execute it as,

$ sh sign.sh prabath

Here, prabath is the alias of the GPG public key.

The following script will generate ASC,MD5 and SHA1 of all the distributions and will also dump the public key to KEYS file.

You should have installed GPG and configured it before running the script.
#!/bin/sh
rm *.asc
rm *.md5
rm *.sha1
rm KEYS
for f0 in *.zip
do
echo $f0
asc=".asc"
md5=".md5"
sha1=".sha1"
f1=$f0$asc
gpg --armor --output $f1 --detach-sig $f0
f2=$f0$md5
gpg --print-md MD5 $f0 > $f2
f3=$f0$sha1
gpg --print-md SHA1 $f0 > $f3
done
gpg --armor --export $1 > KEYS

How to debug a shell script ?

2010-12-05T10:37:00.002+05:30
Simple but very useful..

$ bash -xv wso2server.sh

Invoking a WCF service secured with Kerberos via WSO2 ESB

2010-12-04T14:09:00.011+05:30
1. Set up WCF service secured with Kerberos - explained in this blog post.

2. Set up the WSO2 ESB to work with Kerberos - explained in this blog post - follow the steps 0,1,2,3 and 4.

3. Create a resource in the WSO2 ESB - embedded registry with the following content - this is the security policy we will be applying to the out going messages from the ESB to the WCF service.

In this example, I created a Resource Collection called 'policies' under /_system/governance and created a Resource called krbpolicy with the following content under /_system/governance/policies.

So, my security policy from the registry is /_system/governance/policies/krbpolicy
<?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy wsu:Id="kerberossignandencrypt"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsp:ExactlyOne>
<wsp:All>
<sp:SymmetricBinding
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:KerberosToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssKerberosV5ApReqToken11 />
</wsp:Policy>
</sp:KerberosToken>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
</sp:SignedParts>
<sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Policy>
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
<sp:MustSupportRefThumbprint />
<sp:RequireSignatureConfirmation />
</sp:Policy>
</sp:Wss11>
<sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:RequireClientEntropy />
<sp:RequireServerEntropy />
<sp:MustSupportIssuedTokens />
</wsp:Policy>
</sp:Trust10>
<rampart:RampartConfig xmlns:rampart="http://ws.apache.org/rampart/policy">
<rampart:timestampPrecisionInMilliseconds>true
</rampart:timestampPrecisionInMilliseconds>
<rampart:timestampTTL>300</rampart:timestampTTL>
<rampart:timestampMaxSkew>300</rampart:timestampMaxSkew>
<rampart:kerberosConfig>
<rampart:property name="client.principal.name">client</rampart:property>
<rampart:property name="client.principal.password">1qaz2wsx$
</rampart:property>
<rampart:property name="service.principal.name">service/myserver@WSO2.COM
</rampart:property>
<rampart:property name="java.security.auth.login.config">jaas.conf
</rampart:property>
<rampart:property name="javax.security.auth.useSubjectCredsOnly">true</rampart:property>
<rampart:property name="kdc.des.aes.factor">4</rampart:property>
<rampart:property name="java.security.krb5.conf">/Users/prabath/clients/wso2esb-3.0.1/repository/conf/krb.conf
</rampart:property>
</rampart:kerberosConfig>
</rampart:RampartConfig>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
In the policy we have to set the absolute path to the krb.conf - at the same time we need to set the username and password of the client who invokes the WCF service appropriately - and this account should be in the Active Directory.

4. Now create a proxy service - and in the InSequence - in the Endpoint pointing to the WCF service, enable security and pick the security policy we set before, from the registry.

The endpoint configuration in the synapse config will look like,
<endpoint name="endpoint_urn_uuid_81768417D4430798591291451112900558002-585115135">
<address uri="http://192.168.2.13/EchoServices/EchoService.svc">
<enableSec policy="gov:/policies/krbpolicy"/>
</address>
</endpoint>
5. Also in the InSequence we need to add a Property mediator and set the following.
<property name="PRESERVE_WS_ADDRESSING" value="true"/>
6. Now in the OutSequence - we need to remove the Security Header coming from the WCF service before the Send mediator in the OutSequence - you can do it with a Header mediator.
<header xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" name="wsse:Security" action="remove"/>
7. Also in the OutSequence we need to add a Property mediator and set the following.
<property name="disableAddressingForOutMessages" value="true" scope="axis2"/>
These two properties [5 & 7] are needed if the back end service is WCF and it is secured using WS-Security and ESB is acting as a passthrough. When communicating with WCF, wsa:to should point to WCF service endpoint (In axis2, it can can point to some other place, still axis2 will dispatch correctly using URL). For the pass through with security case, client should sign wsa:headers (WS-Security requirement) and hence wsa:to cannot be changed by ESB (violation of signature); Hence, the requirement for "preserve addressing". When the response comes from WCF->ESB, ESB adds addressing header regardless of whether the original message (from WCF) has addressing or not. In above case, since wsa:headers of request is signed by client, response from WCF will contain a signed wsa headers. If ESB adds one more set of addressing headers, then it will be violating protocol. Hence the requirement for "disable addressing for out messages"

8. Now your InSquence will like,
<inSequence>
<property name="PRESERVE_WS_ADDRESSING" value="true" scope="default" type="STRING"/>
</inSequence>
9. OutSequence will look like,
<outSequence>
<property name="disableAddressingForOutMessages" value="true" scope="axis2"/>
<header xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" name="wsse:Security" action="remove"/>
<send/>
</outSequence>
10. That's it :)

Kerberos authentication with WSO2 ESB

2010-12-04T13:19:00.004+05:30
0. Set up the Active Directory as the KDC as in my previous blog post.

1. Download WSO2 ESB 3.0.1 from here unzip and apply the patches patch0003 and patch0023.These patches are not publicly available - but will be added in to the future releases. If you interested, please contact us on bizdev@wso2.com.

2. Create a file called krb.conf inside [ESB_HOME]\repository\conf and copy the following content to it.
[libdefaults]
default_realm = WSO2.COM
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
dns_lookup_kdc = true
dns_lookup_realm = false

[realms]
WSO2.COM = {
kdc = 192.168.2.10
}
Here, WSO2.COM is my root domain name of my Active Directory, which is acting as the KDC and 192.168.2.1 is it's IP address - so you need to change them as per your setup. Make sure that you have default_realm all caps.

3. Create a file called jaas.conf inside [ESB_HOME]\repository\conf and copy the following content to it.
Server {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=tfalse
storeKey=true
useTicketCache=false
isInitiator=false;
};
Client {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=false;
};
4. Start the WSO2 ESB

5. Apply security to the given proxy service [during this sample we select echo sample service which is already there by default]

6. Select 'Sign & Encrypt with Anonymous' from the Security Policy wizard.

7. After applying, edit the policy and replace both bindings with the content below.
<?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy wsu:Id="kerberossignandencrypt"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsp:ExactlyOne>
<wsp:All>
<sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:KerberosToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssKerberosV5ApReqToken11/>
</wsp:Policy>
</sp:KerberosToken>
</wsp:Policy>
</sp:ProtectionToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:OnlySignEntireHeadersAndBody/>
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body/>
</sp:SignedParts>
<sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:MustSupportRefThumbprint/>
<sp:RequireSignatureConfirmation/>
</sp:Policy>
</sp:Wss11>
<sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:RequireClientEntropy/>
<sp:RequireServerEntropy/>
<sp:MustSupportIssuedTokens/>
</wsp:Policy>
</sp:Trust10>
<rampart:RampartConfig xmlns:rampart="http://ws.apache.org/rampart/policy">
<rampart:timestampPrecisionInMilliseconds>true</rampart:timestampPrecisionInMilliseconds>
<rampart:timestampTTL>300</rampart:timestampTTL>
<rampart:timestampMaxSkew>300</rampart:timestampMaxSkew>
<rampart:kerberosConfig>
<rampart:property name="service.principal.password">1qaz2wsx$</rampart:property>
<rampart:property name="javax.security.auth.useSubjectCredsOnly">true</rampart:property>
<rampart:property name="java.security.krb5.conf">/Users/prabath/clients/wso2esb-3.0.1/repository/conf/krb.conf</rampart:property>
</rampart:kerberosConfig>
</rampart:RampartConfig>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
You need to set your SPN password under service.principal.password and also the absolute path to krb.conf under java.security.krb5.conf.

8. You can write the Java client to this service as explained in my previous blog post.

Kerberos authentication with WCF Service and Java Client

2010-12-04T12:34:00.004+05:30
1. Go through this previous post and get the WCF Service running properly with the Kerberos authentication.

2. Download the Kerberos java client Eclipse project from here - import it in to an Eclipse workspace and fix the missing references - all the jars available inside [WSO2_ESB_HOME]\repository\components\plugin. You can download WSO2 ESB 3.0.1 from here.

3. rampart-core, rampart-policy and wss4j should be picked from patch0003 and patch0023. These patches are not publicly available - but will be added in to the future releases. If you interested, please contact us on bizdev@wso2.com.

4.Make sure the Eclipse project compiles.

5. Configuration files

5.1. krb.conf
[libdefaults]
default_realm = WSO2.COM
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
dns_lookup_kdc = true
dns_lookup_realm = false

[realms]
WSO2.COM = {
kdc = 192.168.2.10
}
Here, WSO2.COM is my root domain name of my Active Directory, which is acting as the KDC and 192.168.2.1 is it's IP address - so you need to change them as per your setup. Make sure that you have default_realm all caps.

5.2 jaas.conf
Client {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=false;
};
You must have this Client section. Here we set useTicketCache=false; so our java client need not to be running from the same Windows domain as the KDC. If you set to true, you need to be in the same Windows domain as the KDC and also edit the Windows registry at the client end - my previous blog post explains how to do that - see #6.

5.3 policy-1.xml
<rampart:kerberosConfig>
<rampart:property name="client.principal.name">client</rampart:property>
<rampart:property name="client.principal.password">1qaz2wsx$
</rampart:property>
<rampart:property name="service.principal.name">service/myserver@WSO2.COM
</rampart:property>
<rampart:property name="java.security.auth.login.config">jaas.conf
</rampart:property>
<rampart:property name="javax.security.auth.useSubjectCredsOnly">true</rampart:property>
<rampart:property name="kdc.des.aes.factor">4</rampart:property>
<rampart:property name="java.security.krb5.conf">/Users/prabath/clients/org.wso2.identity.esb.kerberos/krb.conf
</rampart:property>
</rampart:kerberosConfig>
This is the security policy of the client and we have to set the path to jaas.conf and the absolute path to the krb.conf - at the same time we need to set the username and password of the client who invokes this - and this account should be in the Active Directory.

Also make a note of, service.principal.name - this is the SPN of the account where the Kerberos service is running under - we set this up in my previous blog post

6. In the KerberosCLient code set the RELYING_PARTY_SERVICE_EPR to you WCF Service EPR http://192.168.2.10/EchoServices/EchoService.svc

7. That's it :)

Kerberos authentication with WCF Service and WCF Client

2010-12-04T00:13:00.006+05:30
1.Environment Setup

- Required Windows 2008 Server + IIS 7 + Active Directory + Visual Studio 2008

1.1 Active Directory

Following image shows my Active Directory configuration which includes two users server and client

Open up a command window and type the following to set the SPN for the user 'server'
:\> setspn -A service/myserver server

1.2 IIS

Open up IIS and create an application pool called 'kerberos'

Then Edit the Advance Settings of the created application pool --> Select 'Identity' (under Process Model) --> Select 'Custom Account' --> set the user 'server' and his password

2.Sample Setup

2.1 Download the sample zip file from here, unzip and open it up in Visual Studio 2008

2.2 Find the following setting in web.config unser EchoService project and change it appropriately.. Here service/myserver is the SPN you create before for the user server.
<identity>
<serviceprincipalname value="service/myserver" />
</identity>
2.3 Build the entire solution

2.4 Deploy the service in IIS with the EchoService.WebSetup project

2.5 While doing 2.4, select the application pool created before in IIS - that is 'Kerberos'

2.6 Make sure the service running properly by accessing it's WSDL

http://localhost/EchoServices/EchoService.svc?wsdl

2.7 Open up the app.config file under EchoClient project and edit the following configuration appropriately..
<identity>
<serviceprincipalname value="service/myserver" />
</identity>
2.8 Correct the End Point address in app.config to point to the deployed service

That's it - now you can run the client from the IDE by setting it as the startup project.

How to fetch HTTPS end point certificate chain via Shell ?

2010-12-03T01:45:00.004+05:30
You can do it through the web browser - and download each and every certificate...

Following is the easy way via shell..
$ openssl s_client -showcerts -connect www.amazon.com:443 > ssl.log

depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)09, CN = VeriSign Class 3 Secure Server CA - G2
verify error:num=20:unable to get local issuer certificate
verify return:0

CtrL+C

$ sed -n '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' ssl.log > cert.pem
The above will save the certificate chain corresponding to www.amazon.com in cert.pem file.
-----BEGIN CERTIFICATE-----
MIIE9jCCA96gAwIBAgIQJfXRLV5vC9Tq8qLJZvO0zjANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwHhcNMTAwNzE1
MDAwMDAwWhcNMTMwNzE0MjM1OTU5WjBnMQswCQYDVQQGEwJVUzETMBEGA1UECBMK
V2FzaGluZ3RvbjEQMA4GA1UEBxQHU2VhdHRsZTEYMBYGA1UEChQPQW1hem9uLmNv
bSBJbmMuMRcwFQYDVQQDFA53d3cuYW1hem9uLmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAvokOoa36fVhqoWrkO+115D7yGffzD/rZ72IQUnv83ZSWqDVr
G1BgLi55rHwuo4HejTf57m5PgsfkEgRVr1dplIzvLlB6bVMPW19iWF7P8t/0Tc5x
toLXhuVPd+SRquS9WmWqniBPOF60i+A2RYCo1SRcRp3xgMBrYqUfJl6uF0cCAwEA
AaOCAdEwggHNMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgMEUGA1UdHwQ+MDwwOqA4
oDaGNGh0dHA6Ly9TVlJTZWN1cmUtRzItY3JsLnZlcmlzaWduLmNvbS9TVlJTZWN1
cmVHMi5jcmwwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMB0GA1UdJQQWMBQGCCsGAQUF
BwMBBggrBgEFBQcDAjAfBgNVHSMEGDAWgBSl7wsRzsBBA6NKZZBIshzgVy19RzB2
BggrBgEFBQcBAQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWdu
LmNvbTBABggrBgEFBQcwAoY0aHR0cDovL1NWUlNlY3VyZS1HMi1haWEudmVyaXNp
Z24uY29tL1NWUlNlY3VyZUcyLmNlcjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBW
FglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAm
FiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcN
AQEFBQADggEBAKgV/fW6WoiZDCo9KLt0gmU/QkchH9R41k2etuwXzRi3nvmD5ek5
io/dPGHXwOvxcjTkTz/nM0CpSZ9EsI2/M7F2laNQIY+PDB5ggl4gmPq/GTMaEqFh
YT+oXLiAmqA03N1SjJiFum3OvOBMqZs4xU1WELrvcoobCGh73VlD5TMbCj+9QyrL
7jQ2Q9Vp18p6g6mr5hXvlOiVZSv2nhFOXw4ZAXahMDYGUvEJ4M/UcRYNgLoSJp6T
Sxxfg0ws0Gk7xZkxxEyPJ75JmqwhPkpd4RjTOURiBBbazNjtPYjSpuOub+sTr/Ft
ftICSDU8L5qg9bxV6qR7it5iC3OcWEEcLFE=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGLDCCBZWgAwIBAgIQbk/6s8XmacTRZ8mSq+hYxDANBgkqhkiG9w0BAQUFADCB
wTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQL
EzNDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5
IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1
dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv
cmswHhcNMDkwMzI1MDAwMDAwWhcNMTkwMzI0MjM1OTU5WjCBtTELMAkGA1UEBhMC
VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU
cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMmVmVyaVNpZ24gQ2xh
c3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDUVo9XOzcopkBj0pXVBXTatRlqltZxVy/iwDSMoJWzjOE3JPMu
7UNFBY6J1/raSrX4Po1Ox/lJUEU3QJ90qqBRVWHxYISJpZ6AjS+wIapFgsTPtBR/
RxUgKIKwaBLArlwH1/ZZzMtiVlxNSf8miKtUUTovStoOmOKJcrn892g8xB85essX
gfMMrQ/cYWIbEAsEHikYcV5iy0PevjG6cQIZTiapUdqMZGkD3pz9ff17Ybz8hHyI
XLTDe+1fK0YS8f0AAZqLW+mjBS6PLlve8xt4+GaRCMBeztWwNsrUqHugffkwer/4
3RlRKyC6/qfPoU6wZ/WAqiuDLtKOVImOHikLAgMBAAGjggKpMIICpTA0BggrBgEF
BQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTAS
BgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwMwVjAo
BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAqBggrBgEF
BQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCsw
KaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMtZzIuY3JsMA4GA1Ud
DwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkwVzBVFglpbWFnZS9naWYw
ITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZLjAlFiNodHRwOi8vbG9n
by52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjApBgNVHREEIjAgpB4wHDEaMBgGA1UE
AxMRQ2xhc3MzQ0EyMDQ4LTEtNTIwHQYDVR0OBBYEFKXvCxHOwEEDo0plkEiyHOBX
LX1HMIHnBgNVHSMEgd8wgdyhgcekgcQwgcExCzAJBgNVBAYTAlVTMRcwFQYDVQQK
Ew5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMyBQdWJsaWMgUHJpbWFy
eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5
OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrghB92f4Hz6getxB5Z/uniTTGMA0G
CSqGSIb3DQEBBQUAA4GBAGN0Lz1Tqi+X7CYRZhr+8d5BJxnSf9jBHPniOFY6H5Cu
OcUgdav4bC1nHynCIdcUiGNLsJsnY5H48KMBJLb7j+M9AgtvVP7UzNvWhb98lR5e
YhHB2QmcQrmy1KotmDojYMyimvFu6M+O0Ro8XhnF15s1sAIjJOUFuNWI4+D6ufRf
-----END CERTIFICATE-----

Curl with HTTPS

2010-12-02T17:23:00.006+05:30
Wrote a blog sometime back on "How to invoke a web service call with curl ?" in RampartFAQ.com - but that doesn't explain how to work with Curl with HTTPS.

Today morning I got a question from one of my colleagues and thought of writing a blog on the $subject in detail..

Let's go with few examples..

1. Invoke https://www.amazon.com
$ curl https://www.amazon.com
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.amazon.com/">here</a>.</p>
</body></html>
2. Above won't print details about the SSL handshake. To view SSL handshake let's use -v as an argument
$ curl -v https://www.amazon.com
* About to connect() to www.amazon.com port 443 (#0)
* Trying 72.21.214.128... connected
* Connected to www.amazon.com (72.21.214.128) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /opt/local/share/curl/curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
* subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=www.amazon.com
* start date: 2010-07-15 00:00:00 GMT
* expire date: 2013-07-14 23:59:59 GMT
* common name: www.amazon.com (matched)
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)09; CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.2 (x86_64-apple-darwin10.5.0) libcurl/7.21.2 OpenSSL/1.0.0b zlib/1.2.5 libidn/1.19
> Host: www.amazon.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 02 Dec 2010 07:22:22 GMT
< Server: Server
< Set-Cookie: skin=noskin; path=/; domain=.amazon.com; expires=Thu, 02-Dec-2010 07:22:22 GMT
< Location: http://www.amazon.com/
< Content-Length: 230
< nnCoection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.amazon.com/">here</a>.</p>
</body></html>
* Connection #0 to host www.amazon.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
This HTTPS connection works fine, because, the client trusts the CA of the Amazon's SSL certificate.

By going through the logs you will see, the CA certificates are verified against the curl-ca-bundle.crt file located at /opt/local/share/curl/curl-ca-bundle.crt

If you have a look at the above file, you will see all the trusted CAs listed there..
Verisign Class 1 Public Primary Certification Authority
=======================================================
-----BEGIN CERTIFICATE-----
MIICPDCCAaUCED9pHoGc8JpK83P/uUii5N0wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTI4MDgwMjIzNTk1OVow
XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQ
VoQYh5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2
yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAFgVKTk8d6Pa
XCUDfGD67gmZPCcQcMgMCeazh88K4hiWNWLMv5sneYlfycQJ9M61Hd8qveXbhpxoJeUwfLaJFf5n
0a3hUKw8fGJLj7qE1xIVGx/KXQ/BUpQqEZnae88MNhPVNdwQGVnqlMEAv3WP2fr9dgTbYruQagPZ
RjXZ+Hxb
-----END CERTIFICATE-----

Verisign Class 3 Public Primary Certification Authority
=======================================================
-----BEGIN CERTIFICATE-----
MIICPDCCAaUCEDyRMcsf9tAbDpq40ES/Er4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAzIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTI4MDgwMjIzNTk1OVow
XzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDJXFme8huKARS0EN8EQNvjV69qRUCPhAwL0TPZ2RHP7gJYHyX3KqhEBarsAx94
f56TuZoAqiN91qyFomNFx3InzPRMxnVx0jnvT0Lwdd8KkMaOIG+YD/isI19wKTakyYbnsZogy1Ol
hec9vn2a/iRFM9x2Fe0PonFkTGUugWhFpwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBABByUqkFFBky
CEHwxWsKzH4PIRnN5GfcX6kb5sroc50i2JhucwNhkcV8sEVAbkSdjbCxlnRhLQ2pRdKkkirWmnWX
bj9T/UWZYB2oK0z5XqcJ2HUw19JlYD1n1khVdWk/kfVIC0dpImmClr7JyDiGSnoscxlIaU5rfGW/
D/xwzoiQ
-----END CERTIFICATE-----
In the case of Amazon, it's Verisign who the CA is..

3. Let's try to invoke https://amazon.com [Not www.amazon.com]
$ curl -v https://amazon.com
* About to connect() to amazon.com port 443 (#0)
* Trying 72.21.210.250... connected
* Connected to amazon.com (72.21.210.250) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /opt/local/share/curl/curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
* subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=www.amazon.com
* start date: 2010-07-15 00:00:00 GMT
* expire date: 2013-07-14 23:59:59 GMT
* SSL: certificate subject name 'www.amazon.com' does not match target host name 'amazon.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'www.amazon.com' does not match target host name 'amazon.com'
This fails.. Why ? It's the same CA which is trusted by the Curl client - but it fails due to the host name verification. The certificate was issued to www.amazon.com - not for amazon.com

4. Let's try to invoke https://amazon.com [Not www.amazon.com] - by disabling SSL validations with the argument -k
curl -v -k https://amazon.com
* About to connect() to amazon.com port 443 (#0)
* Trying 72.21.210.250... connected
* Connected to amazon.com (72.21.210.250) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /opt/local/share/curl/curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
* subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=www.amazon.com
* start date: 2010-07-15 00:00:00 GMT
* expire date: 2013-07-14 23:59:59 GMT
* common name: www.amazon.com (does not match 'amazon.com')
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)09; CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.2 (x86_64-apple-darwin10.5.0) libcurl/7.21.2 OpenSSL/1.0.0b zlib/1.2.5 libidn/1.19
> Host: amazon.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 02 Dec 2010 07:38:04 GMT
< Server: Server
< Location: https://www.amazon.com/
< Content-Length: 231
< Cneonction: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://www.amazon.com/">here</a>.</p>
</body></html>
* Connection #0 to host amazon.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
This succeeds.. since we asked Curl to ignore SSL validation issues..

5. Let's try to invoke a service with a certificate issued from a CA not trusted by Curl. I am using WSO2 ESB here - which ships with a self-signed certificate - so, obviously not trusted by Curl
$ curl -v https://localhost:9447/carbon
* About to connect() to localhost port 9447 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 9447 (#0)
* successfully set certificate verify locations:
* CAfile: /opt/local/share/curl/curl-ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
* Closing connection #0
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
You will see, above fails since server certification is not trusted.

6. Let's improve step-5 - by asking Curl to trust our CA certificate.
$ curl -v --cacert esbcert.pem https://localhost:9447/carbon
Here we specify CA certificate of the ESB - with the argument --cacert

Notes :

1. To find the path of the trusted CA bundle

$ curl-config --ca

2. To set your own trusted CA bundle

$ export CURL_CA_BUNDLE=my-ca-bundle.crt

Hand-crafting TCP/IP handshake with Scapy

2010-12-02T01:25:00.007+05:30
The following video explains TCP/IP 3-way handshake - and later we are going to hand-craft the packets used in TCP/IP handshake with Scapy.

First lets define the server and the client,

Server : 192.168.2.1
Client : 192.168.2.11

First I will start Scapy at the client side, to track the packets flowing in between client and the server
$ sudo scapy

>>> a=sniff(filter="tcp")
Now lets open up another console in the client end and start Scapy again..
$ sudo scapy
Welcome to Scapy (2.1.0)
>>>
Step - 1

Now, first create an IP packet - you may notice the src is set to the client IP and the dst been set to the server IP.
>>> ip=IP(src="192.168.2.11", dst="192.168.2.1")
Then, we need to create a TCP packet with SYN - see the flags been set to "S". And we are also setting a sequence number...

Step - 2
>>> SYN=TCP(sport=1500, dport=80, flags="S", seq=100)
Then we need to send the crafted packet. With this we are expecting SYN ACK from the server.

Step - 3
>>> SYNACK=sr1(ip/SYN)
But, if you press Ctrl+C and then a.nsummary() on the other console we are running Scapy, you will see an RST been sent from the client after the SYN.
$ sudo scapy
>>> a=sniff(filter="tcp")
Ctrl+C
>>>a.nsummary()
0000 Ether / IP / TCP 192.168.2.11:1500 > 192.168.2.1:www S
0001 Ether / IP / TCP 192.168.2.11:1500 > 192.168.2.1:www R
Linux kernel automatically sets appropriate header values and knows how to complete a TCP 3 way handshake.

Scapy does not use these kernel services. It creates a raw socket.

In the previous case, as soon as the kernel sees the SYN/ACK it responded with a RST - because it did not send the SYN [it was through Scapy].

So, we need to avoid this behavior and this is how we do it. We can use iptables on our host to suppress outbound RSTs to the destination we are working with.

sudo iptables -A OUTPUT -p tcp --tcp-flags RST RST -s 192.168.2.11 -dport 1500 -j DROP

Once the above done performs steps 1 to 3 and you won't see an RST been sent from the client.

Step - 4

Now the client needs to send ACK for the server's SYN.

Here you will see the sequence number is increased by one and the the sequence number from the SYN ACK form the server been set as the ack.
>>> ACK=TCP(sport=1500, dport=80, flags="S", seq=101 ack=SYNACK.seq)
Step - 5

Send the client ACK to the server
>>>send(ip/ACK)
Step - 6

Let's go back to the first console window and view the flow between client and the server
$ sudo scapy
>>> a=sniff(filter="tcp")
Ctrl+C
>>>a.nsummary()
0000 Ether / IP / TCP 192.168.2.11:1500 > 192.168.2.1:www S
0001 Ether / IP / TCP 192.168.2.1:www > 192.168.2.11:1500 SA
0002 Ether / IP / TCP 192.168.2.11:1500 > 192.168.2.1:www A

Simulating a Smurf attack with Scapy

2010-11-30T17:19:00.003+05:30
Wikipedia says..
The Smurf attack is a way of generating significant computer network traffic on a victim network. This is a type of denial-of-service attack that floods a target system via spoofed broadcast ping messages.

This attack relies on a perpetrator sending a large amount of ICMP echo request (ping) traffic to IP broadcast addresses, all of which have a spoofed source IP address of the intended victim.

If the routing device delivering traffic to those broadcast addresses delivers the IP broadcast to all hosts, most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply, multiplying the traffic by the number of hosts responding.

To simulate a Smurf attack we need to do the following..

1. Install Scapy

On Mac this is how you do it..

On Ubuntu : sudo apt-get install python-scapy

2. Send a large amount of ICMP request to the broadcast address of the victim network(Directed Broadcast Address).

3. Source IP of the attacker must be spoofed.

As per [2] when we send a ICMP request with a spoofed IP been set to the broadcast IP of the network, the server will broadcast the ICMP response to the entire network..

In the following example with Scapy, we are not using a broadcast IP - instead using an IP address of a different machine in the network.

Target machine IP : 192.168.2.11
Server machine IP : 192.168.2.10

From the attackers machine, I start Scapy;

$ sudo scapy

Then type the following - you can see the source IP been spoofed to the target machine IP.

>>> send(IP(src="192.168.2.11", dst="192.168.2.10")/ICMP())

That's it - since we want to confirm the response from the server, 192.168.2.10 goes to 192.168.2.11 - I am also running scapy there too..

$ sudo scapy

>>> a=sniff(filter="icmp and src 192.168.2.11")

The above will trace ICMP traffic targeting 192.168.2.11 - after sometime press Ctrl+C and type the following on the target machine..

>>> a.nsummary()
0000 Ether / IP / ICMP 192.168.2.11 > 192.168.2.10 echo-request 0

Smurf attacks can be prevented by,

1. Configuring the individual hosts and routers not to respond to ping requests.
2. Configuring routers not to forward packets directed to broadcast addresses.

WSO2 @ University of Peradeniya Job Fair

2010-11-29T15:22:00.002+05:30
University of Peradeniya Job Fair was held in Colombo - at IESL last Friday..

Following is the presentation we did - well, there is a story around - you can build it your own :)

Installing Scapy on Mac OS X

2010-11-29T13:09:00.002+05:30
I wouldn't have written this blog post, if everything went well for me while doing the $subject..

I was trying with MacPorts - it gave me the following error..

:error:configure db46 requires the Java for Mac OS X development headers.
:error:configure Download the Java Developer Package from:
:error:configure Target org.macports.configure returned: missing Java headers
:debug:configure Backtrace: missing Java headers while executing
"$pre $targetname"

By going through some of the MacPorts tickets found out that we need to have Java for Mac OS X 10.6 Update 3 Developer Package installed first - which you can get from here.

Once that is done, only following is needed..

$ sudo port install scapy

Kerberos Debugging Tips

2010-11-25T14:24:00.004+05:30
I worked on adding Kerberos support for Apache Rampart and WSS4J during last few weeks and interop testing with WCF.

Following lists some useful debugging tips I came across..

1. How to list all the Kerberos tickets issued to the logged in client principal in Windows
c:\Program Files (x86)\Resource Kit>klist

Current LogonId is 0:0x29a6f

Cached Tickets: (2)

#0> Client: administrator @ WSO2.COM
Server: krbtgt/WSO2.COM @ WSO2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
Start Time: 11/25/2010 13:19:58 (local)
End Time: 11/25/2010 23:19:58 (local)
Renew Time: 12/2/2010 13:19:58 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1> Client: administrator @ WSO2.COM
Server: service/myserver @ WSO2.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
Start Time: 11/25/2010 13:19:58 (local)
End Time: 11/25/2010 23:19:58 (local)
Renew Time: 12/2/2010 13:19:58 (local)
Session Key Type: RSADSI RC4-HMAC(NT)

2. How to remove cached Kerberos tickets in Windows
c:\Program Files (x86)\Resource Kit>klist purge

Current LogonId is 0:0x29a6f
Deleting all tickets:
Ticket(s) purged!

3. How to publish Kerberos error logs in to the Event Viewer in Windows

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
The Parameters subkey stores configuration options for the Kerberos V5 authentication protocol in Windows Server 2003/2008.

LogValue
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry does not exist in the registry by default. The default value is false - to publish to to Event Viewer set it to 1

Following are some more registry entries related to Kerberos...

AllowTgtSessionKey
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry controls whether session keys are exported with initial or cross-realm TGTs. This entry does not exist in the registry by default. The default value is false due to security concerns.

CacheS4UTickets
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry enables and disables Service-for-User (S4U) caching. This entry does not exist in the registry by default. The default value is true.

ClientIpAddresses
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry controls adding IP addresses in KRB_AS_REQ, thus forcing the Caddr field to contain IP addresses in all tickets. This entry does not exist in the registry by default. The default value is false, due to potential DHCP client and network address translation (NAT) issues.

DefaultEncryptionType
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry controls the default encryption type for PreAuth. This entry does not exist in the registry by default. The default value is KERB_ETYPE_RC4_HMAC_NT.

FarKdcTimeout
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry controls the time-out interval, in minutes, that is used to invalidate a domain controller from a different site in the domain controller cache. This entry does not exist in the registry by default. The default value is 10 minutes.

KdcBackoffTime
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry specifies a time value, in seconds, between successive calls to the Key Distribution Center (KDC) if the previous call failed. This entry does not exist in the registry by default. The default value is 5 seconds.

KdcSendRetries
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry controls the number of retry attempts that a client makes in order to contact a KDC. This entry does not exist in the registry by default. The default value is 3.

KdcWaitTime
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

This entry specifies a time value, in seconds, that is used to time out the Winsock calls. This entry does not exist in the registry by default. The default value is 5 seconds.

KerbDebugLevel
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

4. How to set a Service Principal Name [SPN] for a user in AD - in Windows
c:\Program Files (x86)\Resource Kit>setspn -A test/wso2 prabath
Registering ServicePrincipalNames for CN=prabath,CN=Users,DC=wso2,DC=com
test/wso2
Updated object

5. How to list all the SPNs of a given user in AD - Windows
c:\Program Files (x86)\Resource Kit>setspn -L prabath
Registered ServicePrincipalNames for CN=prabath,CN=Users,DC=wso2,DC=com:
test/wso2
service/myserver

6. How to make java clients work with IWA

By default, Windows does not allow the session key of a TGT to be accessed. Add the following registry key on the client side, so that the session key for TGT is accessible and Java can use it to acquire additional service tickets.

For Windows XP and Windows 2000, the registry key and value should be:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

For Windows 2003 and Windows Vista, the registry key and value should be:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

FOSDEM Tech Talks

2010-11-24T01:31:00.007+05:30
Secure communications with Jabber

AMQP

MySQL High Availability Solutions

Mac OS X 10.6 terminal gets so long to load

2010-11-23T16:54:00.001+05:30
This is something I faced after using the MacBook Pro for a month long...

Following is the solution..

sudo rm -f /private/var/log/asl/*

Make sure, you backed up any logs you require before executing the above...

Capturing via tcpdump to view in Wireshark

2010-11-22T23:34:00.001+05:30
$sudo tcpdump -i en1 -s0 -w captured.pcap

-i Listening interface

-s Snarf snaplen bytes of data from each packet rather than the default of 64K bytes. Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause pack- ets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in. Setting snaplen to 0 means use the required length to catch whole packets.

Setting up WSO2 P2 Repo Locally

2010-11-22T15:33:00.002+05:30
Currently WSO2 doesn't host the P2 repository as a single distribution to download - so whenever you want to add a new Feature, you need to point your Carbon instance to the online p2 repo hosted at http://dist.wso2.org/p2/carbon/releases/3.0.0/

This is how you can download the entire repository and set it up locally..

$ pwd

/Users/prabath/p2_repo

$ wget -r -l inf http://dist.wso2.org/p2/carbon/releases/3.0.0/

The above will download the entire P2 repo to the local machine.

Once that is done, go to the running carbon instance, Configure --> Features --> Settings --> Add Repository --> Select Location as Local and set it as, /Users/prabath/p2_repo/dist.wso2.org/p2/carbon/releases/3.0.0 and that's it...

Building and installing MacPorts on Mac OS X 10.6 from source

2010-11-22T12:28:00.002+05:30
The MacPorts project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system.

1. svn co http://svn.macports.org/repository/macports/trunk/base/ macports

2. cd macports

3. ./configure

4. make

5. sudo make install

6. sudo /opt/local/bin/port -v selfupdate

To test the setup, lets try to install MySQL via MacPorts...

1. export PATH=/Developer/usr/bin:/Developer/usr/sbin:/opt/local/bin:/opt/local/sbin:$PATH

2. sudo port install mysql5-server

SSL Debugging - Part - II - Intercepting traffic between WSO2 Carbon FE and BE

2010-11-19T08:21:00.009+05:30
All WSO2 products are based on WSO2 Carbon, which sits as the core for all of them.

We do have a clear Front-End [FE], Back-End [BE] separation - where the FE web application talks to the BE, via web service calls.

This benefits the end user - which adds the flexibility of developing his own client to the corresponding back end functionality in a language independent manner.

All UI components you see in the default distribution talk to the BE services via SOAP over HTTPS.

In case of digging in to an issue - since this is on HTTPS - it's hard to intercept the communication channel and figure what exact messages being passed from FE to BE.

This is how you can do it - to intercept messages flowing over SSL.

Prerequisites:
1. ssldump
2. The private key of WSO2 Carbon, in PEM format - you can download it from here.

Run the following command from where you have the private key, and start any WSO2 Carbon based product - say on HTTPS port 9443

:\> sudo ssldump -Ad -k wso2carbon.pem -p wso2carbon -i lo0 host localhost and port 9443

Make sure to have the correct interface set as per your system.[-i lo0] and start the ssldump before you start the server.

Now you can track all the messages between FE and BE in clear text.
1 8 0.0621 (0.0007) C>SV3.1(203) application_data
---------------------------------------------------------------
POST /services/AuthenticationAdmin HTTP/1.1
Content-Type: application/soap+xml; charset=UTF-8; action="urn:login"
User-Agent: Axis2
Host: localhost:9443
Transfer-Encoding: chunked

---------------------------------------------------------------
1 9 0.0626 (0.0005) C>SV3.1(399) application_data
---------------------------------------------------------------
173
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Body>
<ns1:login xmlns:ns1="http://authentication.services.core.carbon.wso2.org">
<ns1:username>admin</ns1:username>
<ns1:password>admin</ns1:password>
<ns1:remoteAddress>0:0:0:0:0:0:0:1%0</ns1:remoteAddress>
</ns1:login>
</soapenv:Body>
</soapenv:Envelope>
0

---------------------------------------------------------------
1 10 0.2071 (0.1445) S>CV3.1(544) application_data
---------------------------------------------------------------
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=37FC902E5E7C6C0D081E28B4DF067A76; Path=/; Secure
Content-Type: application/soap+xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 19 Nov 2010 02:44:26 GMT

11f
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Body>
<ns:loginResponse
xmlns:ns="http://authentication.services.core.carbon.wso2.org">
<ns:return>true</ns:return>
</ns:loginResponse>
</soapenv:Body>
</soapenv:Envelope>

Installing Wget on Mac OS X

2010-11-18T20:10:00.000+05:30
1. Download from http://ftp.gnu.org/pub/gnu/wget/wget-1.9.1.tar.gz

2. cd ~/Downloads/wget-1.9.1

3. ./configure

4. make

5. sudo make install

6. wget http://dist.wso2.org/products/esb/java/3.0.1/wso2esb-3.0.1.zip

SSL Debugging - Part - I

2010-11-18T02:47:00.003+05:30
We've been involved in many cases solving issues related to SSL.

The latest one I came across was at a customer site, where WSO2 ESB wants to communicate with an SSL end point(WCF) hosted on IIS 7.

The only thing here what we have to do is, importing the CA certificate of the WCF end point to the ESB's client-trustore.jks [which is under ESB_HOME\resources\security].

This worked well at the start - but in one machine it started to fail - with no clue at all..

This is where we need some handy SSL debugging tools - and the easiest one is setting the system property javax.net.debug=all. For example you need to start the WSO2 ESB as,

:\> sh wso2server.sh -Djavax.net.debug=all

Once you set this, it will print the entire SSL handshake.

By going through the logs, we could figure out the issue - where by mistake in this particular machine, in IIS, for this end point - 'Require SSL' being set to Accept, instead of Ignore.

What does that mean.. and why did that fail..?

When we set the above parameter to Accept, the server validates the client certificate only if it's been sent in the request from the client.

In our case at the ESB end we set following two system properties,

System.setProperty("javax.net.ssl.keyStore", "keyStorePath");
System.setProperty("javax.net.ssl.keyStorePassword", "password");

When you set these two, the client will automatically attach the client certificate to the SSL handshake - in our case it failed because we were not expecting mutual authentication, so IIS didn't trust ESB as a client.

Another tool comes in handy while SSL debugging is openssl s_client.

There was a case, where WSO2 ESB talking to an SSL end point behind an Apache server - in that case all the configuration options we provided didn't work - so the option left behind was to test the SSL setup of the Apache server in an independent manner - and proved us Apache server had issues in SSL setup. There we used openssl s_client. For example if you want to verify the SSL handshake with the end point, localhost:9443, you can use the following command.

:\>openssl s_client -connect localhost:9443 -state -nbio 2>&1 | grep "^SSL"

The above will result in the following out put.
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
SSL_connect:SSLv3 read server hello A
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
SSL handshake has read 1149 bytes and written 293 bytes
SSL-Session:
To see all the options available with s_client, type the following,

:\>openssl s_client --help

Let's finish off the first part of the SSL debugging series with ssldump.

ssldump is an SSL/TLS network protocol analyzer. It identifies TCP connections on the chosen network interface and attempts to interpret them as SSL/TLS traffic. When it identifies SSL/TLS traffic, it decodes the records and displays them in a textual form to stdout.

:\>sudo ssldump -i en1 port 443

The above prints following [only a part displayed], when I visit https://cloud.wso2.com.
New TCP connection #1: 192.168.1.3(49986) <-> ec2-184-73-175-181.compute-1.amazonaws.com(443)
1 1 0.3614 (0.3614) C>S Handshake
ClientHello
Version 3.1
cipher suites
Unknown value 0xc00a
Unknown value 0xc009
Unknown value 0xc007
Unknown value 0xc008
Unknown value 0xc013
Unknown value 0xc014
Unknown value 0xc011
Unknown value 0xc012
Unknown value 0xc004
Unknown value 0xc005
Unknown value 0xc002
Unknown value 0xc003
Unknown value 0xc00e
Unknown value 0xc00f
Unknown value 0xc00c
Unknown value 0xc00d
Unknown value 0x2f
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
Unknown value 0x35
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
Unknown value 0x32
Unknown value 0x33
Unknown value 0x38
Unknown value 0x39
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
compression methods
NULL
1 2 0.7638 (0.4023) S>C Handshake
ServerHello
Version 3.1
session_id[32]=
22 24 f7 6c 43 84 ba 39 6f b9 02 5c 4d 76 cf 97
ad b4 39 1b 82 fe c1 cf d7 5b 14 41 87 bd 6a 81
cipherSuite Unknown value 0x2f
compressionMethod NULL
1 3 1.1691 (0.4053) S>C Handshake
Certificate
1 4 1.1691 (0.0000) S>C Handshake
ServerHelloDone
1 5 1.1749 (0.0058) C>S Handshake
ClientKeyExchange
1 6 1.1749 (0.0000) C>S ChangeCipherSpec
1 7 1.1750 (0.0000) C>S Handshake
1 8 1.5787 (0.4037) S>C ChangeCipherSpec
1 9 1.5787 (0.0000) S>C Handshake
1 10 1.5794 (0.0006) C>S application_data
1 11 2.1889 (0.6095) S>C application_data
1 12 2.1889 (0.0000) S>C application_data
1 13 2.1889 (0.0000) S>C application_data
1 14 2.1889 (0.0000) S>C application_data
1 15 2.1889 (0.0000) S>C application_data
1 16 2.1889 (0.0000) S>C application_data
1 17 2.1889 (0.0000) S>C application_data
1 18 2.1889 (0.0000) S>C application_data
1 19 2.1896 (0.0007) C>S Alert
1 2.1902 (0.0005) C>S TCP FIN
New TCP connection #2: 192.168.1.3(49987) <-> ec2-184-73-175-181.compute-1.amazonaws.com(443)
2 1 0.3662 (0.3662) C>S Handshake
ClientHello
Version 3.1
resume [32]=
22 24 f7 6c 43 84 ba 39 6f b9 02 5c 4d 76 cf 97
ad b4 39 1b 82 fe c1 cf d7 5b 14 41 87 bd 6a 81
cipher suites
Unknown value 0xc00a
Unknown value 0xc009
Unknown value 0xc007
Unknown value 0xc008
Unknown value 0xc013
Unknown value 0xc014
Unknown value 0xc011
Unknown value 0xc012
Unknown value 0xc004
Unknown value 0xc005
Unknown value 0xc002
Unknown value 0xc003
Unknown value 0xc00e
Unknown value 0xc00f
Unknown value 0xc00c
Unknown value 0xc00d
Unknown value 0x2f
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
Unknown value 0x35
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
Unknown value 0x32
Unknown value 0x33
Unknown value 0x38
Unknown value 0x39
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
compression methods
NULL
2 2 0.9732 (0.6070) S>C Handshake
ServerHello
Version 3.1
session_id[32]=
22 24 f7 6c 43 84 ba 39 6f b9 02 5c 4d 76 cf 97
ad b4 39 1b 82 fe c1 cf d7 5b 14 41 87 bd 6a 81
cipherSuite Unknown value 0x2f
compressionMethod NULL
2 3 0.9732 (0.0000) S>C ChangeCipherSpec
2 4 0.9732 (0.0000) S>C Handshake
2 5 0.9735 (0.0003) C>S ChangeCipherSpec
2 6 0.9736 (0.0000) C>S Handshake
2 7 0.9737 (0.0001) C>S application_data
2 8 1.6900 (0.7162) S>C application_data
2 9 1.6900 (0.0000) S>C application_data
2 10 1.6900 (0.0000) S>C application_data
2 11 1.6900 (0.0000) S>C application_data
2 12 1.6900 (0.0000) S>C application_data
2 13 1.6900 (0.0000) S>C application_data
2 14 1.6900 (0.0000) S>C application_data
2 15 1.6900 (0.0000) S>C application_data
2 16 1.6903 (0.0002) C>S Alert
2 1.6909 (0.0006) C>S TCP FIN
New TCP connection #3: 192.168.1.3(49988) <-> ec2-184-73-175-181.compute-1.amazonaws.com(443)
3 1 0.3674 (0.3674) C>S Handshake
ClientHello
Version 3.1
resume [32]=
22 24 f7 6c 43 84 ba 39 6f b9 02 5c 4d 76 cf 97
ad b4 39 1b 82 fe c1 cf d7 5b 14 41 87 bd 6a 81
cipher suites
Unknown value 0xc00a
Unknown value 0xc009
Unknown value 0xc007
Unknown value 0xc008
Unknown value 0xc013
Unknown value 0xc014
Unknown value 0xc011
Unknown value 0xc012
Unknown value 0xc004
Unknown value 0xc005
Unknown value 0xc002
Unknown value 0xc003
Unknown value 0xc00e
Unknown value 0xc00f
Unknown value 0xc00c
Unknown value 0xc00d
Unknown value 0x2f
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
Unknown value 0x35
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
Unknown value 0x32
Unknown value 0x33
Unknown value 0x38
Unknown value 0x39
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
compression methods
NULL

Forgot My Password

2010-11-13T21:01:00.004+05:30
Almost all online services provide a way to recover your password, in case you forget it.

And this is the first thing a hacker will look into, to gain control of your account.... so, this is something we need to design carefully...

Let's look at different ways this feature being implemented by major online service providers..

Secret Questions with Yahoo

- You need to set your Secret Questions at the time you sign up - and later you can change if you wish
- But - you need to make sure you set strong secret questions for the first time - if you set weaker ones there your account can be compromised at any time - even you change it later..
- Make sure answers to your secret questions cannot be found via any of your social networking profiles..
- What if somebody gain control of your account via the secret questions? and later change the original secret questions to a different set
- Yahoo still let you gain the control back
- You can go through 'Forgot Password' flow and ask for your original secret questions [not the ones the attacker did set]
- Then you can gain access to your account, but you will never be able to change the original secret questions, so if the attacker knows the original, he can comeback anytime and get the control of your account once again.
- A captcha being used

Password reset link to the email with Google

- You need to have a secondary email address registered
- Secondary email address is not shown to the user during the process of password recovery
- Password reset link being sent to the secondary email address and that link is valid only for a limited time frame
- Even though the password recovery link being sent - still the user can login with the original password, if resetting was not done
- No temporary passwords generated
- Once the password resetting initiated a mail being also sent to the original email address, so if this is an attacker who is doing this, the actual owner of the email account get to know something is going on
- A captcha being used

Password reset code with Facebook

- You need to have either an email address or mobile number registered with your account
- Once you initiate password resetting process, a code will be sent to you
- You need confirm the receipt of the confirmation code to reset the password
- Till you reset the password, you can use the original password to login
- No captcha being used

Password reset link to the email with Twitter

- Need to have an email address registered
- Password reset link being sent to the email address and that link is valid only for a limited time frame
- Even though the password recovery link being sent - still the user can login with the original password, if resetting was not done
- No temporary passwords generated
- No captcha being used

Original password sent back to the email

- Forget them, they store your passwords in clear text

Generate a temporary password and send back to the email

- This is better than the previous one
- Since the original password being replaced by the temporary one, if initiated by an attacker, the true owner won't be able to login till he rest again or check his email
- Should be protected with a captcha

.NET Client / Web App - Authorization with WSO2 Identity Server, XACML Engine

2010-11-11T17:53:00.000+05:30
1. Download the WSO2 Identity Server 3.0.1 from http://wso2.com/products/identity-server/

2. Start the Identity Server and go to https://localhost:9443/carbon - then go to Policies --> Entitlement and add a new XACML Policy - then replace the default one with the one below.

The XACML policy below addresses following authorization requirements.

- The operation getVesrion1 and getVersion2 in the service /services/Customers should be accessed by any user

- Request to any other service or operation should only be accessed by the users belong to the group(s) admin_emps or admin or both
<?xml version="1.0" encoding="UTF-8"?>
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Actions>
<AnyAction/>
</Actions>
<Resources>
<AnyResource/>
</Resources>
</Target>
<Rule Effect="Permit" RuleId="primary-resource-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/services/Customers/getVersion1</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/services/Customers/getVersion2</AttributeValue>
</Apply>
</ResourceMatch>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/services/Customers/getVersion1</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/services/Customers/getVersion2</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule Effect="Permit" RuleId="primary-group-emps-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">/services/Customers/</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<SubjectAttributeDesignator AttributeId="group" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin_emps</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="deny-rule"/>
</Policy>

3. Download the .NET client from hear - unzip it - edit the app.config to point to correct EPRs where your Identity Server [XACML engine] is running.

4. You can parse the XML response returned from the XACMl engine to get the decision.

Guide to write XACML policies in WSO2 Identity Server - Part - 7

2010-11-11T10:25:00.001+05:30
This blog post is a follow up to the Guide to write XACML policies in WSO2 Identity Server - Part - 6.

This post addresses following authorization requirements.

1. The operation getVesrion1 and getVersion2 in the service http://localhost:8280/services/Customers should be accessed by any user

2. Request to any other service or operation should only be accessed by the users belong to the group(s) admin_emps or admin or both
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Actions>
<AnyAction/>
</Actions>
<Resources>
<AnyResource/>
</Resources>
</Target>
<Rule Effect="Permit" RuleId="primary-resource-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getVersion1</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getVersion2</AttributeValue>
</Apply>
</ResourceMatch>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getVersion1</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getVersion2</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule Effect="Permit" RuleId="primary-group-emps-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<SubjectAttributeDesignator AttributeId="group" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin_emps</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="deny-rule"/>
</Policy>

Guide to write XACML policies in WSO2 Identity Server - Part - 6

2010-11-11T09:28:00.001+05:30
This blog post is a follow up to the Guide to write XACML policies in WSO2 Identity Server - Part - 5.

This post addresses following authorization requirements.

1. The operation getEmployees in the service http://localhost:8280/services/Customers should only be accessed by the users belong to the group(s) admin_emps or admin or both

2. Request to any other service or operation should fail

3. But the users admin1 and admin2 should be able to access any resource irrespective of their role
<?xml version="1.0" encoding="UTF-8"?>
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Actions>
<AnyAction/>
</Actions>
<Resources>
<AnyResource/>
</Resources>
</Target>
<Rule Effect="Permit" RuleId="primary-user-rule">
<Target>
<Subjects>
<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string" SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin1</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin2</AttributeValue>
</Apply>
</SubjectMatch>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<SubjectAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin1</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin2</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule Effect="Permit" RuleId="primary-group-emps-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getEmployees</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<SubjectAttributeDesignator AttributeId="group" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin_emps</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="deny-rule"/>
</Policy>

Guide to write XACML policies in WSO2 Identity Server - Part - 5

2010-11-11T03:22:00.002+05:30
This blog post is a follow up to the Guide to write XACML policies in WSO2 Identity Server - Part - 4.

This posts addresses following authorization requirements.

1. The operation getEmployees in the service http://localhost:8280/services/Customers should only be accessed by the users belong to the group(s) admin_emps or admin or both

2. Request to any other service or operation should fail
<?xml version="1.0" encoding="UTF-8"?>
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Actions>
<AnyAction/>
</Actions>
<Resources>
<AnyResource/>
</Resources>
</Target>
<Rule Effect="Permit" RuleId="primary-group-emps-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getEmployees</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
<SubjectAttributeDesignator AttributeId="group" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin_emps</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="deny-rule"/>
</Policy>

Guide to write XACML policies in WSO2 Identity Server - Part - 4

2010-11-11T03:07:00.003+05:30
This blog post is a follow up to the Guide to write XACML policies in WSO2 Identity Server - Part - 3.

This post addresses following authorization requirements.

1. The operation getEmployees in the service http://localhost:8280/services/Customers should only be accessed by the users belong to both the groups admin_emps and admin

2. If the user belongs to more groups than admin_emps and admin - request should fail

3. Request to any other service or operation should fail
<?xml version="1.0" encoding="UTF-8"?>
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Actions>
<AnyAction/>
</Actions>
<Resources>
<AnyResource/>
</Resources>
</Target>
<Rule Effect="Permit" RuleId="primary-group-emps-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getEmployees</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-set-equals">
<SubjectAttributeDesignator AttributeId="group" DataType="http://www.w3.org/2001/XMLSchema#string"/>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin_emps</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin</AttributeValue>
</Apply>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="deny-rule"/>
</Policy>

Guide to write XACML policies in WSO2 Identity Server - Part - 3

2010-11-11T02:05:00.004+05:30
This blog post is a follow up to the Guide to write XACML policies in WSO2 Identity Server - Part - 2.

This post addresses following authorization requirements.

1. The operation getCustomers in the service http://localhost:8280/services/Customers should only be accessed by the users belong to group admin_customers

2. The operation getEmployees in the service http://localhost:8280/services/Customers should only be accessed by the users belong to group admin_emps

3. Request to any other service or operation should fail
<?xml version="1.0" encoding="UTF-8"?>
<Policy PolicyId="urn:sample:xacml:2.0:samplepolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">
<Description>Sample XACML Authorization Policy</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Actions>
<AnyAction/>
</Actions>
<Resources>
<AnyResource/>
</Resources>
</Target>
<Rule Effect="Permit" RuleId="primary-group-customer-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getCustomers</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-subset">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin_customers</AttributeValue>
</Apply>
<SubjectAttributeDesignator AttributeId="group" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Condition>
</Rule>
<Rule Effect="Permit" RuleId="primary-group-emps-rule">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-regexp-match">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">http://localhost:8280/services/Customers/getEmployees</AttributeValue>
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-subset">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">admin_emps</AttributeValue>
</Apply>
<SubjectAttributeDesignator AttributeId="group" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="deny-rule"/>
</Policy>
Following are few valid requests which will result in "Permit/Not Applicable/Deny" once evaluated against the above policy.

XACML request - 1
Resource : http://localhost:8280/services/Customers/getCustomers
User : "admin" belongs only to "admin_customers" group
Result : Permit
<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Subject>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>admin</AttributeValue>
</Attribute>
<Attribute AttributeId="group"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>admin_customers</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>http://localhost:8280/services/Customers/getCustomers</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>read</AttributeValue>
</Attribute>
</Action>
<Environment />
</Request>

XACML request - 2
Resource : http://localhost:8280/services/Customers/getCustomers
User : "admin" belongs only to "admin_emps" group
Result : Deny
<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Subject>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>admin</AttributeValue>
</Attribute>
<Attribute AttributeId="group"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>admin_emps</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>http://localhost:8280/services/Customers/getCustomers</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>read</AttributeValue>
</Attribute>
</Action>
<Environment />
</Request>

1. Go to beginning of the current line	Ctrl + A
2. Go to the end of the current line	Ctrl + E
3. Copy the current path	$ pwd \| pbcopy
4. Clear the screen [same as clear]	Ctrl + L
5. Display all the environment variables	$ env
6. Deleting from current position to the end of the line	Ctrl + K
7. Deleting from current position to the beginning of the line	Ctrl + U
8. Deleting the first word before current position	Ctrl + W
9. Move the cursor a letter back from the current position	Ctrl + B
10. Move the cursor a letter forward from the current position	Ctrl + F
11. Open current location in Finder window	$ open .
12. Open a file with unknown extension with the default editor	$ open -t file.ext
13. Watch a particular file to see who's opening it	sudo opensnoop -f PathToTheFile
14. Text-to-speech	say "HI"
15. Runs the last command again	!!
16. Hold option and click a position in the current line to move your cursor to that position.
17. List all possible commands	Hit and hold ESC