At this point I am a JavaScript newbie, I have assiduously avoided a full fledged dive into the language until recently. That is difficult to believe as at least 50% of my job involves ASP.NET. However, the introduction of some really cool libraries has forced me into a desperate game of catch up.

One of my recent tasks was to try calling a web service from Javascript using Visual Studio 2005 and the obvious solution involves the use of XMLHttpRequest. The following sample solution covers a HTTP POST while passing a couple of simple parameters.

var oReq = getXMLHttpRequest(); 

if (oReq != null) {
    oReq.open("POST", "http://localhost/mydemo.asmx", true);
    oReq.onreadystatechange = handler; //call back function defined below
    oReq.send(“param1=22&name=Michael";);
}
else {
    window.alert("AJAX (XMLHTTP) not supported.");
} 

function getXMLHttpRequest() 
{
    if (window.XMLHttpRequest) {
        return new window.XMLHttpRequest;
    }
    else {
        try {
            return new ActiveXObject("MSXML2.XMLHTTP.3.0");
        }
        catch(ex) {
            return null;
        }
    }
} 

//called when the service returns
function handler()
{
    if (oReq.readyState == 4 /* complete */) {
        if (oReq.status == 200) {
            alert(oReq.responseText);
        }
    }
}

This works great but I wanted to look at sending more complex data structures (which for java scripts generally refers to arrays) in a really intuitive way. This sounded simple but I started to run into weird things when trying to send anything but regulars vars. I did happen upon a really intuitive JavaScript library created by Mateo Casati, called SoapClient. It provides great support for all the types of arrays and even classes, the only real limitation in what you can send is JavaScript itself.

<script type="text/javascript" src="soapclient.js"></script>
var url = "http://localhost/mydemo.asmx");

function handler(r)
{
    alert(r);
}

function MyNewSample() {
    var list = "This is a test";
    
    var pl = new SOAPClientParameters();
    pl.add("list", list);
    SOAPClient.invoke(url, "MyNewSample", pl, true, handler);
}

This option became almost immediately obsolete once I was given permission to use Visual Studio 2008 for the project. In VS2008 I am able to take advantage of the ScriptManager (as well as break points in JavaScript). This inferred upon me all the intellisense support for my web service that I would need for rapid development. It simply requires that you place the following script inside a form tag.

<asp:ScriptManager runat="server" ID="scriptManager">
    <Services>
        <asp:ServiceReference path="mydemo.asmx" />
    </Services>
</asp:ScriptManager>

FriendFeed appears to be a Twitter clone that improves on the original, it allows you and your friends to chat about the minutia of life and get updates about each other regularly (not attractive to me, but it takes all sorts). I was looking through the API documentation just wondering what they may have available and this was the blurb they produced on authentication.

If you are publishing data to FriendFeed or if you are requesting the feed that includes data from a user with a private feed, your HTTP requests must be authenticated.

All FriendFeed users have a Remote Key to provide third party applications access to their FriendFeed. A FriendFeed Remote Key is just like a password, except that it is only used for third party applications, so it only provides access to the functionality defined by the API. Users can easily reset it if a third party application abuses the API.

 

All requests that require authentication use HTTP Basic Authentication. The username should be the user's nickname, and the password should be the user's Remote Key.

Now this fledgling company is being endorsed by some interesting bloggers, but I think the lack of an OAuth implementation is a real problem. They are getting around it by effectively giving you a public password (referred to as a Remote Key), this is quite separate to your actual password.

There are a few problems I foresee with this approach. Firstly you only get one Remote Key and if you want to stop access to your personal data for one particular app you must reset the Remote Key. Unfortunately when you reset your remote key you actually reset it for everyone and therefore need to update the key for everyone. They could get around this by providing management of multiple keys to multiple third party apps, that way you could cut access to any given app without disrupting others, but who would honestly want to do that.

Secondly this practice still plays into the basic problem of the password anti pattern, even though this is a a public password the level of control given means that this is still the basic user name and password paradigm. Either way we look at this it still better than the Twitter security option, where Basic Auth rules supreme, real account passwords are given out, and session cookies last forever, I will not go into detail about Twitter as this method is appropriately lambasted here.

I have had a series of posts recently about various, supposedly responsible, Social websites asking for my username and passwords (email), and another post about not so trustworthy sites asking for Live Services passwords. I had resolved to only be concerned about sites that were clearly not taking advantage of the OAuth security pattern, however, it is quite difficult to explain to a layman if a site is using OAuth or taking short cuts of storing your password, logging in and doing some kind of screen scraping. I hope to address this here.

Why do we even need something like OAuth? Well if you are, like me, a user of the something like Live services, but you would love to be able to import all your contacts from a social network like LinkedIn. You have a couple of options, hope that LinkedIn allows you to export the contacts in some common format (csv, xls, etc) and also hope that Windows Live offers a compatible import solution … or … you need an Open secure API which both services can comprehend, vis-a-vis OAuth (I will not go into the details of the OAuth pattern, except to say that it overcomes the need to send user id and password with every request sent to a third party, like BasicAuth).

In short when a site is responsible enough to employ the OAuth open protocol you can gain access to secure areas (contacts, photos, etc) of other sites without spreading your password everywhere. A good example of this pattern can be seen at work in the Windows Live Services. I go through the steps of selecting the import process from LinkedIn, as shown below.

This is the really important part here! After clicking next I am redirected to the LinkedIn web site for authorization. What you should not be doing at this point is adding your LinkedIn credentials into the Windows Live site. This is always a bad idea! To be clear I trust both LinkedIn and Windows Live, I just do not believe they need the keys to each others houses.

Any system that teaches users that it is ok to put passwords from one site into another is really doing us all a disservice, this password Anti Pattern teaches people that it is ok to give away your password. This bad habit ensures that people will be more likely to be caught in Phishing scams the world wide web over. Many social networks have spread like this and LinkedIn is as guilty as any of them.

For me the design of this LinkedIn import page is really problematic. While it appears to redirect authentication for Windows Live and Yahoo,  for Gmail, AOL and the Others options it relies on you putting user names and passwords directly into the LinkedIn site.

I am sure that LinkedIn is being above board and responsible with my information (am I) but this pattern is doing the overall security of the web no good. They are teaching a whole generation of Social network users that this type of password sharing is ok.

What is more confusing is that AOL and Gmail appear to have OAuth implementations (AOL OpenAuth, Google AuthSub) yet LinkedIn seems to disregard this and teach bad habits to its users.

Hopefully in a future post I will go through some code that complies with the OAuth pattern.

Service oriented development is dominating my current programming landscape. Service Oriented Architecture (SOA) can be defined as loosely coupled software services that support requirements of a business process. SOA is also characterized by being technology agnostic, that is, the underlying service can be implemented in a variety of ways RPC, DCOM, CORBA or Web Services without worrying about the source.

Currently most of the projects I am involved with consume web service where the underlying technology is completely unknown to me. As with all banking systems security is always key so I wanted to review some of the options available for someone using ASP.NET.

Windows - Basic: Used for non-secure identification of clients, as the user name and password are sent in base 64-encoded strings in plain text. Passwords and user names are encoded, but not encrypted, in this type of authentication. A determined, malicious user equipped with a network-monitoring tool can intercept user names and passwords, this type of authentication is generally limited to secure networks.

Windows - Basic over SSL: Used with secure identification of clients in Internet scenarios. The user name and password are sent over the network using Secure Sockets Layer (SSL) encryption, rather than plain text. This is relatively easy to configure and works for Internet scenarios. However, using SSL degrades performance.

Windows - Digest: Used for secure identification of clients in Internet scenarios and uses hashing to transmit client credentials in an encrypted manner so the password is not transmitted in clear text. In addition, Digest authentication can work through proxy servers. However, it is not widely supported on other platforms.

Windows - Integrated Windows: Uses NTLM or Kerberos. Uses a cryptographic exchange with the user's Microsoft Internet Explorer Web browser.

Windows - Client Certificates: Use for secure identification of clients in Internet and intranet scenarios. Requires each client to obtain a certificate from a mutually trusted certificate authority. Certificates are optionally mapped to user accounts, which are used by IIS for authorizing access to the XML Web service.

SOAP headers – Custom: Useful for both secure and non-secure Internet scenarios. User credentials are passed within the SOAP header of the SOAP message. The Web server, regardless of the platform hosting the XML Web service, provides a custom authentication implementation.

"The mystery of government is not how Washington works but how to make it stop." - PJ O'Rourke