WCF Service Method Level Security using Message Contract

January 31, 2012 § Leave a comment




This article illustrates how to implement security for a service method, in the context of custom authentication, confidentiality and integrity, using Message Contract. The message is packed with authentication information at the client side in the MessageHeader. The Service intercepts this message and validates the credibility of the consumer client. Besides, we will also check, using Message Contract how can sign or encrypt partial header information and all body information in a message.

Real Life Scenario

There could a service method which is passing sensitive information over the wire and you want to take some exclusive security measure for the service method in question. You can pack a security token in the relevant message header for the service method and validate the same in the service end before returning response. Also, since the information in the message is highly sensitive, you can sign and encrypt the message. We will implement this kind of service method level authentication and message level security for a specific service method, using Message Contract in this article.

Implementing the WCF Service

In order to implement the above discussed concept, we will develop a simple WCF service project. The WCF service has a GetAccountsData method which returns AccountsInfo of a customer on validatingCustomerCredential passed as input.

The types passed and returned by the service method are defined as Message Contract. In order to Sign/Encrypt the Message parts, we will use protection level. There are three basic levels of protections that exist for any part of a message:

  • None.
  • Sign. The protected part is digitally signed. This ensures detection of any tampering with the protected message part.
  • EncryptAndSign. The message part is encrypted to ensure confidentiality before it is signed.

In order to set protection level, use System.Net.Security namespace.

The CustomerCredential Message Contract contains a MessageHeader element SecurityToken, which is being validated at service end.

One thing to keep in mind, the SOAP Body has only one protection level, even if you have multiple body parts with different protection levels. In case of AccountsInfo Message Contract, the highest protection level off all body parts will be taken (in our case, EncryptAndSign). SOAP headers can have different protection levels. I have deliberately set different protection level in Message body in order to establish this behavior. We will verify this on checking the HTTP traffic.

Implement the service method. If the SecurityToken matches, the method returns AccountsInfo for the customer, otherwise throws security exception.

The default WCF binding BasicHttpBinding does not support protection level. We need to introduce a wsHttpbinding for our service. In order to introduce a wsHttp binding, make an entry in the web.config file as follows:

 Collapse | Copy Code
      <service name="MyWCFService.MyService">
        <endpoint address="" binding="wsHttpBinding" contract="MyWCFService.IMyService"/>

Right click -> View in Browser on the file MyService.svc in order to check the WSDL generated by the WCF service.

Publish the Service in Internet Information Server(IIS)

We could have called the service without publishing it in IIS. But at the end, we are also going to check the Sign/Encryption of messages. We will be checking HTTP traffic using Fiddler tool while the service is being consumed by some client application. For this purpose, we need to publish it in IIS (sometimes Fiddler creates problems while inspecting localhost traffic. There are workarounds for this, but it’s better to publish the service in IIS). Right click on the WCF service application project and click on publish. Create a virtual directory named WCFVW in IIS and publish the service. Modify the target location with your pc name.

Browse the newly published service in the browser:

Click on the service link and check the WSDL.

Calling the Service

We will create a simple console application in order to consume the service. Add a Console application project. Right click on the References->Add Service Reference. Type the WCF service URL in the Address box.

Once you click on OK, the stub code will be generated. Open Program.cs and add the following namespaces:

Implement the following code in order to call the service using channel factory. The SecurityToken is being set in the MessageHeader. If the credential matches, the retrieved account detail for the Customer is being printed, otherwise the Fault thrown by the service is displayed in the console.

Run the console application. The accounts information will be retrieved as the SecurityToken is matched at the service end.

Now modify the client code in order to pass a different SecurityToken.

Run the Console application. Fault will be thrown from the service due to the mismatch in the SecurityToken.

Checking Message Sign/Encryption

We are now done with the project and it is time to sniff the HTTP traffic between service and client in order to verify desired Sign/Encryption in our Message Contract. Run the HTTP data inspector Fiddler. Now, run the console application in order to call the service. Check the service request traffic:

The request traffic consists of the message parts SecurityToken as MessageHeader and CustomerID asMessageBodyMember in the Message Contract CustomerCredential. Since we have set protection level to “EncryptAndSign” for MessageHeader, the SecurityToken has been signed and encrypted. Also, theMessageBodyMember CustomerID is visible as its protection level is set to “None”.

Now check the response message. The returned Message Contract AccountsInfo does not have anyMessageHeader. It has got MessageBodyMembers with different protection level. As I have mentioned earlier, the SOAP Body has only one protection level, even if you have multiple body parts with different protection levels. In this case, the highest protection level of all body parts, EncryptAndSign is taken and the entire messagebodybecomes signed and encrypted.


(Source : CodeProject)

Before jumping into cloud, learn from the SOA experience

January 30, 2012 § Leave a comment

Summary: Companies need to look at service-oriented approaches — and what has been learned over the past decade — before taking on a potentially entangling and silo-creating cloud engagements.

You want expensive and duplicated service entanglements?  You want huge silos? That’s what cloud computing may bring enterprises that can’t manage and govern the process. All these issues have already been worked out in SOA settings, and companies that have worked with SOA approaches within their business technology are much better prepared to move into cloud computing than those not as familiar with SOA.

That’s the view of Thomas Erl, who is a best-selling and perhaps the most prolific IT author on the planet, and a passionate proponent of the “service technology” revolution reshaping enterprise systems. I recently caught up with Thomas, who is also CEO of Arcitura Education Inc., a service technology education and certification provider, incorporating SOASchool.com and CloudSchool.com, who discussed how SOA has prepared enterprises for today’s cloud computing endeavors.

Before moving into cloud, there’s much to learn from the SOA experience, he points out. “Companies who have gone ahead and adopted SOA, have gone through a number of project lifecycles, and are delivering services are using that experience and knowledge in cloud computing technology.”

Before moving to cloud, companies that have not yet adopted SOA practices to “reach out to other organizations that have gone through the SOA lifecycle, to fully understand what it is they’re establishing, what it is they’re building, and the commitments of ownership are,” Thomas says.

Companies need to look at service-oriented approaches — and what has been learned over the past decade — before taking on a potentially entangling and silo-creating cloud engagements. “It’s easier to build silos in the sky in the cloud than on-premise,” Thomas points out. “You can build nice big monolithic applications that don’t connect with anything, and only fulfill immediate automation requirements, and then work your way towards a beautiful integration nightmare in the future where everything has to rely on point-to-point fragile type of integration architectures. And you can build that wonderfully using the infinite resources of the cloud, you can build it out for eternity. You’ll just have that ever-growing albatross around your organization’s neck as it tries to have its IT environment keep up with how the business needs to evolve and change.”

A lot of these integration and governance issues have already been worked out within SOA efforts in recent years, Thomas says. For companies contemplating cloud, “the SOA community has already done the work for them,” says Thomas. “Everything’s there  and documented now, in terms of models, patterns, and principals and best practices.”

Take a serious look at what SOA can provide, he urges. “The models that support SOA will formalize the cloud environment. Whether its SOA or another formal model. You want to formalize that environment, because if you just use the resources in a tactical manner, as your business needs them and fulfill it that way, you’re just repeating the cycle of silo-based applications leading to integration architectures leading to IT.”

Those who have gone through the SOA lifecycle “will have more of an appreciation for the nature of the risk factors with cloud,” Thomas continues. “Because you need to be able to govern your ecosystem, govern your services, and work toward a specific target state. There are definite concrete advantages to leveraging cloud resources, to maximize the business requirements potential, and fulfill a potential with those resources. But there are also very concrete, very real risks that come with that. The more you understand how much your business depends on these services, the more they’ve been reused, the more you’ve already gone through cases where you’ve had services crash, because the usage has been too high, or they’ve been attacked, or certain failover in house hasn’t worked, the more you can appreciate what a cloud environment can bring.”

By Joe McKendrick


8 Things You Ought to Know If You Do Not Know Anything About Hiring A Software Developer

January 23, 2012 § Leave a comment

“The one absolutely solid place to store your capital today — if you know how to do it – is in software developers’ wallets.”

…is what Venkatesh Rao states in his thought provoking article “The Rise in Developeronomics” published Dec 5, 2011 on Forbes. He argues that the future of our economy will be heavily dependent upon access to software development services as starting, growing, and running your business is bound to involve software nowadays. So he makes the case that the best friend to have to face these challenges is… a software developer.

I did not come to this industry with a software background. I studied math, physics, business, then finance. But over the past 12 years or so, I have learned quite a bit about how to pick a software… “friend”. So let me share with you 8 things I would want to know if I was starting afresh.

I would ask about the development process. I seem to take it for granted that all software shops operate on some type of “Agile” development methodology. The reality is much different. Beware of a once favorite software development process named the “Waterfall Model”, a sequential model in which steps are completed one after the other. First the customer would specify ALL requirements, then the app would be designed and coded, then — and lots of time is elapsing here as you’d progress thru the steps — it would be tested; then deployed. The drawbacks of this process is that it’s lengthy, unresponsive to change and yes, super costly. So the process you want your software friend to abide by is an Agile one. Because an Agile process calls for short development “iterations”, you get value in short increments of time. In a nutshell, it’s a collaborative process that delivers quickly and enables you to adapt to change.

I would ask about the development practices. Just like you would expect of your accountant to abide by certain Generally Accepted Accounting Principles, you ought to expect that your software “friend” abide by the following practices.

  1. The first one on my list would be TDD: Test Driven Development. No later than yesterday, I produced a spreadsheet that summarizes how an amount of money gets allocated amongst different accounts. In doing so, one could easily forget to include a cell. To put TDD in perspective to the non developer, my test to avoid such a situation would be to have a cell in which the formula tests that the sum of the parts would equal the whole, before even starting the allocation. A good software friend practices that as a reflex. Before writing any code, he or she writes tests to ensure that the code to be written will produce the desired outcome.
  2. The second one would be pair programming. If you have ever looked even remotely at code, it’s a lot of text. To me it may be mostly gibberish, but it does not take much convincing to understand that two sets of eyes are better than one. So hopefully, your friend has a friend, because, that will ensure less bugs.
  3. The third one is those short iterations we talked about earlier.
  4. The fourth one is continuous integration. This means that your friend is diligent about integrating to the rest of the system as a whole. It ensures that everybody’s work works together.

I would ask how my potential software “friend” would keep his or hers claws sharp. Again, just as you would expect your accountant to be aware of the changes in tax laws, you should expect your software friend to be aware of the changes in the software industry. My software friends usually go to conferences, read books, reflect on their work whether through blogging or presenting to others, and meet with other fellows in the field. They know several languages and work across multiple platforms. Better yet, they fear not learning a new one. Above all, they are far from being the stereotypical isolated geek one could envision.

I would ask for proof of talent. Although a degree from an ivy league university might do the trick for some, quality experience does set the good developer apart. My developer friends have loads to show to testify for their talent. For some, from past work done, for others, from apprenticeship projects, but for all, from hands on development.

I would ask about how they estimate. Systems built nowadays have variable scope. As a result, it can be difficult to estimate how long the project will take. However, I would advise you to befriend a developer that gives you a reasonable estimate. An estimate that could provide you with a bracket of possible values: one pessimistic, one optimistic, and one realistic. I may even push it to ask with what confidence do past project estimations fall within a 95% accuracy within the aforementioned brackets.

I would ask how deadlines are met. Deadlines are a critical variable for any business. If I were to befriend a software developer I would expect to hear that since the development process relies on short iterations and prioritization of requirements, I (the customer) hold the key to deadlines. I (the customer) would be the one prioritizing which features get attended first. I (the customer) would hence have control on where my ROI would come from.

I would ask about cost. Of the upmost importance, staying within one’s budget is a goal that short iterations can help to fulfill. When getting value in short iterations, cost is easy to tame. Prioritization ensures that the most financially critical decisions stay within the hands of the customer. A good software development friend will bill at a certain frequency of iteration completions.

I would ask about change. I would say to my potential friend: “How will my app be able to evolve overtime?” — deeply concerned with the ever changing technologies, market requirements, and products I could offer. I would expect him to state that he values feedback and collaboration. A good software developer friend embraces change in requirements which are bound to happen overtime. Oh, and do I need to stress again that a good software friend develops in short iterations, which by itself, guarantees an adaptable progress?


Angelique Martin

Microsoft raises ‘state of the art’ son of NTFS

January 18, 2012 § Leave a comment

Microsoft raises ‘state of the art’ son of NTFS

Will join forces with Storage Spaces in Windows 8

By Gavin Clarke


Microsoft has unveiled a “state of the art” file system for the next 10 years that builds on NTFS.

Named Resilient File System (ReFS), Microsoft’s latest baby will be delivered with Windows 8 Server and become the foundation of storage on Windows Clients.

ReFS will be used with Windows 8’s Storage Spaces, a feature in Microsoft’s forthcoming Windows 8 Client that pools storage for use by different machines. Storage Spaces and ReFS have been designed to complement each other as components of a “complete storage system”.

“We believe this significantly advances our state of the art for storage,” Windows storage and file system development manager Surendra Verma wrote Monday on the Building Windows 8 blog. Verma wrote:

We will implement ReFS in a staged evolution of the feature: first as a storage system for Windows Server, then as storage for clients, and then ultimately as a boot volume. This is the same approach we have used with new file systems in the past.

NTFS was introduced by Microsoft in Windows NT in 1993 and has penetrated deep into computing. Verma and his boss, Windows group president Steven Sinofsky, stressed that ReFS does not replace NTFS and that it builds on the existing system. ReFS reuses NTFS code responsible for the Windows file system semantics, Verma said.

“This code implements the file system interface (read, write, open, close, change notification, etc), maintains in-memory file and volume state, enforces security, and maintains memory caching and synchronization for file data. This reuse ensures a high degree of compatibility with the features of NTFS that we’re carrying forward,” he wrote.

The difference between ReFS and NTFS is that the code uses a new engine to implement on-disk structures, such as the Master File Table, to represent files and directories. It’s this machinery, Verma wrote, “where a significant portion of the innovation behind ReFS lies”.

By working with Storage Spaces, ReFS tries to protect data from partial and complete disk failures, and will remove data from the name space on a live volume where information has been corrupted. Meanwhile a process has been added that periodically scrubs metadata and Integrity Stream data on volumes living on a mirrored Storage Space.

The initial focus of ReFS will be on its role in file servers, especially with mirrored Storage Spaces. “We also plan to work with our storage partners to integrate it with their storage solutions,” Verma wrote.

The overall thinking of ReFS seems to be data and file management and a recovery system built from the ground up for peers and nodes of all sizes while handling increasing quantities of big data. NTFS dates from a time when departmental-level and LAN-levels of scale inside the corporate firewall were the goal. ®

Scratch Shield: Nissan Introduces World’s First Self-Healing iPhone Case

January 17, 2012 § Leave a comment

scratch shield feat

An iPhone case from Nissan? As you can imagine, it would make no sense for the automaker to develop an ordinary case, and the so-called Nissan Scratch Shield iPhone Case is actually special. According to the company, it’s the world’s first “self-healing” iPhone cover: in other words, it quickly fixes (fine) scratches by itself.

Nissan says they used their self-healing paint finish originally developed for vehicles for the case, which is made from light weight ABS plastic. Scratch Shield as a paint technology has been used in various Nissan cars since 2005, before Nissan teamed up with the University of Tokyo and Japan-basedAdvanced Softmaterials [JP] to create the case.

Nissan explains:

The outer ‘paint’ is made from polyrotaxane, which means that when damage occurs to the coating in the form of a fine scratch, the chemical structure is able to react to change back to its original shape and fill the gap – ‘healing’ the blemish.

The company distributed a number of prototype iPhone cases to journalists and “customers” and might commercialize the product later this year. Mobile carrier Docomo is already offering the NEC N-03B, a feature phone using Scratch Shield, on the Japanese market.

ARROWS μ F-07D: Fujitsu’s Android Phone Is Waterproof And 6.7mm Thin, Comes With 4-Inch OLED

January 17, 2012 § 1 Comment

The Infobar C01 from yesterday was a bit too much for you? Not to worry, Japan still produces “ordinary” Android phones: Fujitsu’s ARROWS μ F-07D [JP], which mobile carrier NTT Docomo plans to start selling this Friday, is the newest example.

It doesn’t look as unique as the Infobar, but the list of specs is long and pretty impressive:

  • Android 2.3
  • 4-inch OLED with 480×800 resolution (Gorilla Glass)
  • 5MP CMOS camera
  • waterproof body that’s just 6.7mm thick (iPhone 4: 9.3mm)
  • MSM8255 Snapdragon processor (1.4GHz)
  • 512MB RAM
  • 1GB ROM
  • DLNA/DTCP-IP support
  • e-wallet function (NFC)
  • infrared connection
  • digital TV tuner
  • microSDHC slot
  • 1,400mAh battery
  • Bluetooth 2.1+EDR
  • Wi-Fi (tethering for up to 8 devices)
  • size: 127×64×6.7mm, weight: 105g

NTT Docomo will be offering the handset in “Sapphire Black” only.

IP Spoofing – is it feasible?

January 17, 2012 § Leave a comment

IP spoofing is the attack used by hackers to steal a user’s IP address. IP spoofing involves spoofing a Transmission Control Protocol (TCP) connection, since IP Addresses are passed within TCP packets. When two hosts want to establish a TCP session, they must synchronize their connection using a TCP mechanism called “3 way handshake”. This mechanism is composed of three phases:

  1. The first packet, with flag SYN, is sent by the client to the server.
  2. The server responds with a SYN-ACK packet.
  3. Finally, the client sends an ACK packet to conclude the 3 way handshake.

From the output of this TCP connection, it’s possible to see a couple of long numbers, the sequence number and the acknowledgment number. These values have a size of 32bit, and are randomly generated by modern operating systems every time a new connection is started. During the session, these numbers are incremented by the number of bytes transmitted. So, for example, if the client sends to the server 6 bytes of data, the acknowledge number (example – 1779314099) is calculated from the sequence number of the client, plus the number of bytes received (1779314093 + 6). On the other side, if now the client wants to send more data, it must use 1779314099 as a sequence number (the number that now the server expects).

IP Spoofing, in the past, was a suitable technique to impersonate a different IP address and defeat security systems (such as firewalls). With the randomization of session numbers, an attacker trying to conduct a remote IP Spoofing must predict the 32bit acknowledge number sent by the server in the middle of the 3 way handshake (the SYN-ACK packet). Assuming that the size of a minimal TCP ACK packet (to conclude the handshake) is 54 bytes, and that the number is (on average) predicted correctly after 2^34/2=2147483648 attempts, the total amount of data the attacker must send is 54*2147483648, which would be 108 Gigabytes of data.

This is clearly not feasible, considering that the server considers invalid the 3 way handshake after a short timeout. The only possible way, at present, to conduct an IP spoofing attack, is to have access to the sequence numbers sent by the legitimate client.

Article By: Emanuele Acri.

Where Am I?

You are currently viewing the archives for January, 2012 at Naik Vinay.