Everyone tolerated Steve. Some even got a kick out of his antics: whenever a successful project was nearing launch, Steve would rush in to "rescue" it. He'd send off warning emails to everyone, saying the testing was not conclusive, the deployment plan was incomplete, and the code was riddled with bugs. Then he'd call for a "weekend crunch" to make things right and slave away as the project's sole martyr when no one else would come in. Granted, he would never actually check-in code or make any other changes, but he'd always take credit for the project. No one bought it, and that's why it was so funny. Well, funny until he was promoted to management.

Steve's new management role was to lead the software architects, who were responsible for designing all of the applications throughout the company. He believed in "leading by example" and wanted to show everyone that he knew what he was going. To do this, he'd need to come up with a new initiative. An impressive initiative. One that would simplify all development across the company. Then it hit him: Web Services.

No one was really sure where Web Services could be used. Well, other than Steve, of course. Steve's vision was to add a set of Web Services to each existing application so that data could be accessed in a uniform method by other applications. This way, if the Accounts Payable system ever needed to know who checked in some code to the Source Control system, it'd be a simple Web Service call. There was just one small thing Steve had to figure out: authorization.

Each application had different authorization rules that determined who was allowed to see what data and used Integrated Windows Authentication to determine who was making the request. The big problem with Integrated Windows Authentication, according to Steve, is that it's not a very Web-Servicey way of doing things. It's complicated to pass credentials "under" the Web Service layer -- be it Integrated Authentication or custom SOAP headers -- and Web Services are all about simplicity.

Steve's Web Service initiative called for all Web Services to allow anonymous access (for simplicity sake) and for each method to be of the following format: 

[WebMethod]
public string WebRequest(string requestXml, string username, string passkey)
{
    if (passkey == "32foi$^")
    {
        return InternalWebRequest(requestXml, username);
    }
    else
    {
        return null;
    }
}

The requestXml parameter contained details about the data being requested, the username was the Windows Username, and the passkey was a password. Kind of. Sort of. Almost. Each Web Service needed to have a hard-coded "passkey" that the calling application would need to send in. This way, you could trust that the username being passed into the function was the real username. It was perfectly secure.

Unfortunately (for us), the submitter of this story didn't stick around long enough to see the Web Service initiative all the way through. He still keeps in touch with a former coworker and, last he heard, their latest challenge is finding a secure way to store all of the WebRequest passkeys in one place, without giving everyone access to all of them. They're thinking of building a Web Service to handle that ...

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!