Jeff Townes

Defeating the Password Anti-Pattern with OpenID

2010-04-05T21:58:00.001-05:00

Most websites provide registered users with access to some type of secure “members only” content, but they ask users to create a new username and password (and remember it each time they return). Unfortunately, we users can’t remember any more passwords. We can barely remember the usernames and passwords for the accounts we have already!

Being overwhelmed is only part of the problem. A larger threat is that users may contribute to their own identity theft. Users often reuse the same username and password at multiple sites as a coping mechanism to simplify the accounts they have to remember. Websites that require an email address as a username exacerbate the problem because users (very often) use the same password for the website login that they use to manage their email account access.

These behaviors all feed something that security experts call the “password anti-pattern” – sharing the username and password from one site with another site. If one site gets hacked, bad guys may have access to other unrelated information.

OpenID provides an effective solution to the online account / identity problem by allowing consumers to use a single account identity to access secure content on multiple websites. Websites that support SSO with OpenID are called “relying parties”, and these sites rely on an issuing provider for identity management and authentication. Account credentials are not shared between sites, so the password anti-pattern is defeated.

Here’s how it works: When a user wishes to access secure content, the relying party website redirects the user to the issuing provider to login, the issuing provider authenticates the user, and then the issuing provider redirects the user back to the relying party after authentication is complete. An alternate user experience delivers similar capabilities using a browser pop-up rather than redirecting across sites.

If interested, you can read the OpenID 2.0 technology specification here: http://openid.net/specs/openid-authentication-2_0.html#anchor2. (Pour yourself a stiff cup of coffee before reading.)

Consumer Single Sign-on using OpenID

2010-04-05T21:09:00.001-05:00

Early this year, I began work with a large Dallas-area client to launch a consumer-facing website that will issue user accounts and deliver single sign-on among and between websites hosted by the company and its partners. The site will enable users to navigate freely across a wide range of web channels: e-commerce, social networking, affinity programs, content delivery sites, and others.

As part of that initiative, our team recommended OpenID 2.0 (http://openid.net/) as the technology solution for consumer SSO:

OpenID is an authentication protocol that makes it easy for people to sign up and access web accounts
OpenID enables single sign-on between web sites using a centrally-maintained username and password
The protocol provides a way for sites to verify the identity of an end user without requesting a password for each site

The typical OpenID implementation involves integrating a given website (the “relying party”) with a separate third-party website (the “issuing provider”) that will issue accounts and manage authentication centrally – the relying party site will rely on the issuing provider for authentication.

OpenID adoption has grown rapidly, and the US Government is piloting a program to manage citizen access to government resources using OpenID: http://openid.net/2010/03/03/open-identity-exchange-commences-open-government-pilot-national-institutes-of-health/

Our project is unique because our client is launching a new issuing provider website and integrating its other web properties with the new issuing provider (as relying parties) for authentication and single sign-on. Few companies choose (or need) to become issuing providers, but the unique shape of this client’s industry offer it a great opportunity. Our team is excited to be helping them deliver – and I am excited to be learning about the emerging technologies in the Identity 2.0 space.

Stay tuned for more…

SQL Server 2008: Allow users to save design changes that require tables to be dropped and re-created

2010-03-17T05:32:00.002-05:00

I discovered today that SQL Server 2008 wants to save me from myself. While I appreciate the intent, I’m beyond salvation. I prefer productivity.
Scenario: I tried to disable null values for a column in our development database, but SQL Server warned me that saving changes will require tables to be dropped and re-created:

Luckily, there’s an easy option to put the user back in control:
Tools > Options > Designers > Table and Database Designers > Prevent saving changes that require table re-creation

I unchecked the flag, and I was in control again. (Or, at least in control of this…)

Information architecture is required to deliver the promised value of SOA

2009-09-20T12:23:00.002-05:00

Last month, I posted that “SOA is limited in its ability to create value for an organization” because services are often not reusable. At some level, developers seem responsible for the failure because we are tasked with developing tailored line-of-business applications, so we do not consider the broader goal of enterprise reusability. And, as I noted in that post, we also have difficulty transitioning from a “build it” mindset to a “find it” approach where we look before we leap into development. At the same time, business stakeholders share responsibility for the failure of SOA. These application owners and line-of-business executives are focused on meeting short-term business needs, and they often shortchange the required ongoing investment in enterprise-wide design, governance, and training.

I believe there is another significant (and overlooked) reason why SOA does not deliver its promised business value: information architecture. By design, services expose endpoints into business application silos. These services cannot be effectively integrated unless they all speak the same language – that is, unless they all understand and share the same information architecture. In the absence of SOA, application developers create line-of-business applications that have their own unique data stores, and they use data synchronization to push and pull information across the enterprise. The design is effective because business owners do not have an expectation that information will be integrated immediately. This architecture does not scale when SOA becomes an IT or enterprise goal.

SOA introduces a significant increase in operational complexity because, suddenly, multiple applications share part of the enterprise picture – but none are complete. The old patterns of nightly sync jobs and data reconciliation are not enough. Business owners demand that at least one of the systems serve as a trustworthy system of record in real time. Developers respond by scheduling hourly (or even more frequent) sync jobs, and the architecture struggles to keep pace with the business demand for high-integrity data.

So, what’s the solution? SOA must be coupled with information architecture so that critical information can be consolidated, not replicated, and multiple applications can share a unified view of master data. Senior management must define enterprise-level business strategy for technology rather than delegating all technology decisions to business units and their line-of-business needs. At the same time, enterprise architects must explain to business unit leaders that the data integrity they demand will only result from tighter integration with the information in other business units. Information architects should outline master data management programs and organize the governance structures required to support them. Technologists must justify these programs based on business objectives, and ultimately, LOB data fiefdoms must be replaced with an enterprise view.

Then, and only then, will SOA deliver its full promised value. Applications will share a common understanding of critical business information. Updates will propagate natively to other applications rather than relying on a Rube Goldberg framework of jobs and packages to synchronize, consolidate, and cleanse data. Data quality will improve, and governance structures will protect its ongoing integrity. Most importantly, business leaders will share a common set of actionable knowledge to drive operations and analytics.

A serious evaluation of information architecture seems absent in many discussions about SOA, but this enterprise information management is the missing link.

Happy Talk Like A Pirate Day!

2009-09-19T11:02:00.001-05:00

I love shamelessly fun-seeking holidays… St. Patrick’s Day, Halloween, and… National Talk Like a Pirate Day! What a great excuse to have a little fun with family and friends. So…

Ahoy! Be ye with me, mateys? Raise yer bottles and scupper yer cutlass! Weigh anchor, sea dogs! It’s now or in Davy Jones’ locker. If not for me, for the rum.

Ay, fair winds to ye!!

Arrrrrrrrrr….

SOA: Does it deliver its promised value?

2009-08-27T15:16:00.002-05:00

Brian Orrell sent me a link to a David Chappell (the SOA expert, not the comedian) blog post titled “Is SOA Failing?”. In his post, Chappell states plainly that the “value [of SOA] is nowhere near as large as we’d hoped.” He goes further in a podcast by saying that “SOA is failing.” Overall, Chappell delivered his usual dose of thought-provoking content and it was a solid message. Key points:

SOA is failing because services are (often) not reusable
The failure is largely human – technology can deliver, but humans struggle to design or consume services in that form
SOA works better when it delivers highly-technical services (e.g. identity management) or when it delivers raw data

…and as a separate nugget, he included a distinction I had not thought about yet:

SOA usually describes services consumed by technologies or developers
SaaS describes consumer-facing services

I wholly agree with David Chappell: SOA is limited in its ability to create value for an organization. Recently, I spent time at a large non-profit organization creating services (and implementing MSE) to centralize user authentication & authorization for a number of .NET applications. Our team developed and exposed new services so that applications could call into a central system for identity management. We also used services to expose raw data: states, countries, members, etc.

The architecture worked well, but the value was elusive . First, abstracting security logic from each application and centralizing it sounds simple, but in practice it was challenging to reuse identical logic for all applications. A bigger limiter was that it took a substantial effort to train and transition the client staff from an “I need to build my own…” mindset to a “I need to go find…” mindset. Arguably, there was significant value lost in translation.

SOA delivered a solution for our need, and the software is serving the organization well. But, SOA did not deliver the enormous value that experts like Chappell once touted that it would. SOA is useful, but I am not convinced that it is game-changing.

What do you think? Is SOA failing?

The Cost of ‘Good Enough’

2009-08-11T19:27:00.002-05:00

A recent Visual Studio Magazine article (The Cost of Static) hints that offshore development can have costly downsides hidden in the form of missed requirements or poor implementations. While I agree that offshore development (or any level of offshore/onshore/nearshore/remote development) can be costly, I think the author missed a bigger risk.

The real cost is the cost of “good enough.” When developers slack and deliver software that is merely good enough, companies lose the opportunity to capitalize on excellent work. Excellent work can attract new customers, lower operating costs, build brands, or help the companies achieve other critical objectives. Errors, re-work, or missed intent can cost companies dearly. Not only do these problems force businesses to invest additional funds, they also jeopardize organizational relationships and goodwill.

Good enough won’t cut it. Unfortunately, there are many developers who deliver “good enough” regularly. This article highlighted one such example. Similar results could have come from a local contractor or an offshore firm. Location is irrelevant. The real caution for businesses is to hire the best talent available to meet business objectives and deliver quality software.

Delivering Quality Software

2009-08-11T17:32:00.002-05:00

Coworkers who know me well will tell you that I am passionate about delivering quality software. I have a mild obsession with unit tests, code coverage, complexity statistics, FxCop analyses, and the like. I get a geeky satisfaction when I pop open a code coverage report during a code review and see coverage stats up in the 90s. And few things are more professionally satisfying to me as a developer than a good code review session where we boil a seemingly complex ball of logic down into a few simple lines. Ah, great success!

Now, I’ll admit that I’m a rare breed. I write lists for everything, I love my Quicken account registers, and I spend an inordinate amount of brain cycles thinking about efficiency (my car-packing skills are the stuff of legend!!). But, while these traits may explain my attention to detail, they don’t explain why I care.

Delivering quality software allows me to innovate faster and deliver more than others who don’t monitor quality.

As a creator/architect/designer, I can try new ideas with the confidence of knowing that bugs will surface immediately. If my code breaks something, automated unit tests will fire error notifications and I will know about the problems – fast. These messages give me the information to address problems quickly before additional logic complicates the fix… and they also give my team the guilty pleasure of asking me to don an obligatory “you broke the build” pink cowboy hat. (We geeks love our build rituals.) As a result, I can try new ideas without investing hours or days in manual regression tests for each trivial change. Effective unit tests take time to write, but they pay me back with dividends.

Since I can innovate faster, I can deliver more. Naysayers and change-phobes no longer can persuade me that it will “take too much time to make a change.” I can refactor with courage and deliver better software.

Plus, it’s fun…

Handy Link for the ASP.NET Page Lifecycle

2009-02-18T11:37:00.002-06:00

Some of us have been building ASP.NET applications since the 1.0/1.1 days when we had to think about (and see) all of the event wiring in the code-behind pages. For developers that are learning ASP.NET web development today, some of the event wiring seems like “magic.”

I have mixed feelings about the helpfulness of these tools. On one hand, “magic” is great for helping new .NET developers become productive quickly, but it’s also a hindrance for those times when knowing the full page lifecycle would be useful. It’s good for developers to know what is happening under the covers.

In case you’d like to learn the ASP.NET page lifecycle (or need a link to send to others who are learning), here is a great link that describes the events and how the fit together:
http://www.beansoftware.com/ASP.NET-Tutorials/Page-Life-Cycle.aspx

Thanks for the link, Danny.

Microsoft Songsmith Rocks!!

2009-01-18T15:35:00.005-06:00

Check out Microsoft Songsmith: http://research.microsoft.com/en-us/um/redmond/projects/songsmith/. We spent some time goofing with it this weekend to blow off steam during a 37-hour code-a-thon, and it's awesome. You sing (whatever comes to mind...) to a beat, and it then adds music to accompany your ramblings and off-pitch vocals. It's like karaoke without any rules, and I'm hooked. It says it's still a "Microsoft Research" product, and the video advertisement is hokey, but the product is almost as entrancing as Rock Band.

DNN serves a purpose, but...

2009-01-18T14:58:00.004-06:00

I spent this weekend working with some of my coworkers to develop a content-managed website for a local charity. We've worked 37 hours since 2:30 PM on Friday, so we're a bit short on sleep... which may explain why I'm feeling feisty.

So, about that feistiness...

DNN is not my favorite tool. For this weekend charity challenge, we developed the website on the DotNetNuke (DNN) platform to ensure that the small staff at our charity would be able to manage it. DNN provides tools to update site content, upload photos and documents, and manage event calendars, announcements, etc. So, it serves a purpose. But, those features come at a cost. The platform is slow, it is cumbersome to style, and it is not a good platform for custom applications. It is a simple CMS platform.

I have developed many DNN sites over the past few years, and I had hoped the performance shortcomings and feature bloat would have been addressed in this new version. I was disappointed to learn that it's still the same ole' DNN... painful.

Our team is happy with the choice to use DNN because it will provide a solid solution for Cedar Hill ISD. It's simple. But, i would not recommend it to any organization with a dedicated IT staff or any organizaiton that wishes to extend it with custom features. Look to a different platform (SharePoint, Sitecore CMS, etc.) instead.

Great working with Cedar Hill ISD Education Foundation

2009-01-18T14:48:00.003-06:00

This year, our We Are Microsoft team developed a new content-managed website for Cedar Hill ISD Education Foundation. You can see the new site at http://www.cedarhillef.org/.

Cedar Hill EF is a foundation that provides programs and academic support for students in the Cedar Hill Independent School District. Their old website, http://www.chisd.org/CHfoundation/index.htm, provided them with a venue to share their mission, but the organization did not have tools to easily manage their message and update site content. We created a new content-managed website with tools for staff to update content, events, and photos. We setup their new domain name, configured new corporate email, created a blog, and setup a Flickr site for them to manage photos of their events.

Many thanks to Microsoft for sponsoring this event!

We Are Microsoft Charity Challenge!

2008-11-18T10:38:00.005-06:00

I've registered again for the We Are Microsoft Charity Challenge. The event benefits charities who need technology support to better serve their communities. It's a fun weekend, so I hope you'll join, too.

Do Not Fool Yourself: Prototype != Production

2008-06-21T13:09:00.002-05:00

As developers, we get attached to our work because we take pride in our accomplishments. The trouble is that we get a little too attached to progress and miss the bigger picture. We build prototypes to vet out our designs, test new technologies, and demonstrate concepts to our colleagues. But, we shouldn’t fool ourselves… prototypes are not production code.

It happens on every project. We begin building a solution to demonstrate our vision to our client / product manager / IT director / business user. But, we take a few shortcuts. Honestly, who hasn’t, right? We skip the unit tests. We may not wire it up to a production-ready data model. And, we sure don’t subject our code to the scrutiny of our peers. After all, it’s a prototype, right? We’re just trying to rally everyone around a vision! We give ourselves the standard line… “oh, I’ll refactor it and add the test cases ‘later’”.

But then “later” arrives. Now we’re invested in this prototype. After all, it is the solution that sold the business on the viability of a few new features, and… it works! Our perspective is skewed. We think… “Gee, why can’t I just start with this and build around it?” (…except that it’s not 1950 and none of us really think like Beaver Cleaver and the “gee” generation…). In any case, we become comfortable with our shortcuts, and we explain them away.

Resist the urge. Just say no. Prototype code should not be in Production.

First, if you treat your prototype as the starting point for your “real” solution, you’re starting on the wrong side of the statistics. You now have 0% code coverage on your unit tests (or maybe a meager 10-15%), which is hardly the mark of excellence on a production-ready product. Nobody wants to start work with a losing record. I encourage our teams to shoot for an ‘A’ average – 90% code coverage on all code. If 90% is good enough for our nation’s universities, then it’s good enough for me.

Next, if you use your prototype as your “real” solution, you inherit your own bad decisions. We’re geeks – educated, intellectual, creative application designers. All of us can find something we don’t like about the code we wrote last year/month/week. Why? We learned something new that improved our habits and made us better developers. Well, the same goes for an individual solution. For some reason, our ideas are always better the second time around. Most likely it’s because we subject our ideas to peer critique and we vet our code through peer reviews. Inspection begets improvement. But, it’s also (at least partially) because we felt some pain along the way as we implemented our solution – we remember the pain, and we work to overcome it the second time around.

So, do yourself a favor. Relegate your prototype code to a “Prototype” branch in Subversion and begin building production-ready code with a new folder from the trunk. Start fresh for your production application. You will thank yourself later.

TFS Project Extraction Tool - Anyone have a solution?

2008-06-06T22:54:00.005-05:00

We are in need of a production-ready tool to extract Team Foundation Server project source code (including all history) from our TFS server so that we can turn it over to clients at the end of each engagement. We have played with the CodePlex projects, but they're still a bit too buggy to rely on.

Doug Seven mentioned this feature will be available in Rosario using a feature called Project Collections. Does anyone know if there are any plans to release a solution sooner? We would like to continue recommending TFS for our clients, but this is a critical requirement that TFS currently cannot meet.

We will likely recommend Subversion until a solution is released.

Agile: More Customer, More Better

2008-06-06T21:41:00.009-05:00

This is it. I just got back from TechEd 2008 in Orlando, and I've got the itch to start blogging. I finally have something to say...

Customers, I want to hear from you. I want as much customer interaction as you can give me.

While at TechEd, I attended a Birds-of-a-Feather (BOF) discussion on Agile Development with .NET. The discussion was an open fishbowl style conversation with questions from the audience and a rotating group of people like me offering up answers from our project experiences with Agile.

Overall, it was an engaging discusssion among techies. Many came to learn about the Agile manifesto and the benefits of Agile so that they could try it with their teams. Some came to pontificate, which is fair game for BOF sessions. But a few, I dare say, were shopping for excuses. They were looking for justifications to avoid customer interaction so they could get back to their true passion - coding.

One attendee, let's call him Joe, personified the problem. During a short Q&A, Joe expressed concern that his customers were not engaged in his projects. They often skipped iteration review meetings, so his team had little opportunity to gather customer feedback. Ok, nothing strange there. We have all heard and felt that before.

The problem surfaced during a later discussion about Joe's project work habits. Joe was frustrated that his team couldn't hit its velocity because his customers continually "bothered" him with questions and ideas. He wished they would "leave him alone" so that he could... code. He felt that customers should save their comments for the iteration review meeting rather than "bother" him during his precious coding time. He didn't see the irony that he was complaining earlier that his customers were not engaged. The truth was that they were engaged when they had something to offer, but he wanted them to play by his rules.

Developers like Joe view Agile as an excuse to avoid customers rather than as a tool to engage them. Comments like Joe's give business executives pause when they hear about Agile. They fear that developers will interpret Agile as "ad hoc" and will isolate themselves from processes designed to encourage communication. In fact, Agile seeks to augment communication rather than isolate it. Joe is misguided.

Developers (and projects) cannot be successful without frequent customer interaction. Customers do not "get in the way" of progress. Instead, they are critical to project success because the feedback customers offer alters the shape and direction of each project. And, that's a great thing. Afterall... they are the customer. It's much more satisfying, personally and professionally, to have happy customers than disgruntled ones. Take time to listen when they come knocking. Make adjustments if you can, and prioritize the rest for later. We want to make our customers happy, right?

So, for any of my customers out there who are reading this... Please, keep "bothering" me. I want to hear from you.