Defeating the Password Anti-Pattern with OpenID

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

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

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

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!

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?

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’

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.