CardSpace De-Mystified at OWASP in Hartford

If you are interested in security, identity management, and web standards; you won't want to miss the next meeting of the local chapter of the Open Web Application Security Project (OWASP) in Hartford tomorrow night. The local chapter holds bi-monthly meetings on topics of interest in this space. OWASP is a community dedicated to promoting the development of secure code and supports the education of not only security architects, but developers.

At tomorrow night's meeting, Chris Winn, a Strategic Security Advisor at Microsoft, will be talking about CardSpace and de-mystifying it a bit. Chris will be touching on several fundamental concepts in the CardSpace..well.space and how it can help exert control of digital identity management in the enterprise and on the web. He'll be touching on:

Agenda: Wednesday, June 11th 2008

CardSpace and ADFS2-Industrial Strength Digital Identity Management

Unum Harnesses SOA for Customer-Oriented Services

The potential benefits of SOA in the enterprise can be great, including reduced cost, better business efficiency and agility, and perhaps most importantly-a much better customer experience. Unum, one of the companies I have recently become acquainted with, saw the opportunity to transform and improve the customer experience and streamline back office operations at the same time. Two years ago, Unum (formerly UnumProvident) embarked on an effort to do just that. They call this ongoing effort Simply Unum and it has begun to bear fruit.

Naturally, the technology and architectural changes needed to empower this kind of business transformation are a lot to get your arms around. Unum faced many of the classic challenges associated with taking tightly-coupled, product-centric systems, organized in silos by lines-of business and transforming them into loosely-coupled, customer-centric set of services and automated business processes. As you can guess, change of this magnitude is never simple, quick or easy. The costs and risks can be substantial. To be successful, I think service-orientation requires a fundamental cultural shift at all levels of the business -Unum definitely seems to have it going on.

The good news is that Tim Fitzgerald and Keith Stackhouse, two members of the architecture team at Unum, are willing to tell us a bit about what they are doing and how they are doing it. They will be presenting at the upcoming 6th Annual Microsoft Financial Services Developer Conference. The technical team is currently in the process of assessing their existing SOA capabilities and defining the future architectural roadmap on this basis. One of the conceptual tools Unum will be using for this assessment is the SOA maturity model (SOAMM). Regardless of whether you are just getting your feet wet with SOA or whether you well on your way and facing some of the service management issues that come with a more mature catalog of services, I think you will find this presentation well worth your while.

As a tool, SOAMM can play different roles depending upon how far along the road to SOA you are at the moment. In the early stages it can provide a vital roadmap to maturity; later on it can provide a valuable assessment tool.  There are other maturity models out there, but most seem to share a focus on capabilities. In SOAMM, for example, extensibility, supportability, repeatability and reusability are measured to determine where good maturity has been reached and where there is more work to be done. To me, however, these technical capabilities-though very important-are really secondary.

Traceability is the master capability and the gold standard of maturity. At the end of the day, all technical capabilities must be directly traceable to specific business needs and capabilities.  The best measure of maturity for SOA is the extent to which the technical capabilities of SOA empower the business. That's what impresses me about Unum; they took this approach from the start. The business sponsors and the technical team have strong alignment on the ultimate objectives of Simply Unum: making it easier for customers to do business with them. I'm looking forward to learning more about how they have achieved success so far and how they plan to continue their success in the future.

In case I haven't made myself clear, I am indeed saying that SOA can enable better customer relationships and better customer experience (UX)-when it's done well. The whizz-bang features in WPF are great, but it doesn't have a monopoly on UX. Very often, services turn out to be a vital organ for great UX. The folks at Unum seem to really get this. My first acquaintance at Unum was Rick Klausner. Rick's official title there is VP of Customer Capabilities and Enterprise Architecture. That's a big title and a big responsibility, but I also think its emblematic of the whole approach for Simply Unum. Customer capabilities first, enterprise architecture second; but the two linked at the hip. When the latter is traceable to the former, you have a good formula for success.

If you can make it to the Developers Conference, I think this is a session you won't want to miss.

Authorization Claims and Stable Data

I spend quite a bit of time thinking about authorization-especially as it pertains to highly distributed computing environments. Authorization gets tricky fast in this environment. Federated scenarios are an excellent case in point. For example, Mary is a doctor in one hospital and she needs to access patient records in another hospital. Not only will she have to be authenticated, Mary will have to be authorized for those specific medical records. Services in the cloud (SaaS) will almost always require the service host to extend this type of limited trust to its bona fide service consumers. Consensus is forming about how to do this. Both authentication and authorization in highly distributed scenarios can be implemented using claims-based assertions in the form of tokens. Token standards (and services) are emerging and converging. Both SAML and WS-Authorization standards are now in the hands of OASIS and will probably be merged.

These token specifications are quite rich and absolutely necessary for building secure interoperable services, but they may not be sufficient. To see why, you have to understand the need for stable data. Keep in mind that at some level claims are themselves just data. Pat Helland has given a lot of thought to what happens when persistent data becomes a message and vice versa in the midst of SOA. Check out Data on the Outside vs. Data on the Inside if you haven't already.

Helland defines stable data as data that is unambiguous throughout space and time. You stabilize data by defining when and where it is valid. As it turn out, this concept is very important for authorization claims. Once you commit to sending messages and receiving messages that contain authorizing claims, you had better commit to defining and assessing when and where these claims are valid as well. Without such definition, authorization claims will infer far greater extension in space and or time than may have been originally intended. Let's suppose that Mary's medical credentials were revoked a moment after she sent her request messages to view various patient records at other hospitals? Those messages might be invalid by the time that they arrive-might they not? You might answer this question by saying that the request is valid as long as it was valid at the time it was initiated; but denying the problem won't may it go away. The problem with services (especially in the cloud) is that response latency (time) is generally undefined and frequently indefinable.

As I said earlier, faced with meeting business and regulatory policy demands in this environment can be tricky. Even if you knew when and where each of Mary's requests were sent, revoking them after the fact is still nearly impossible once the proverbial train has left the station. For example, there is no practical way to ensure that the revocation message can or will be processed before Mary's request; just as there is no practical way to know how long it will take to process a given request. This is why it's better to stabilize claims before they go out the door and check them as soon as they arrive.

Don't be misled into thinking that it's only the request that must be stabilized. Each claim (and perhaps each claim set) may have a different extent in space and time. In fact, that may be required in order to implement certain access control policies for individuals who have multiple roles. To use some spatial examples, Mary's medical credentials have been revoked in one state but they are still valid in another. My driver's license may still be valid even though the registration on my car has expired. When claims are constructed in one domain, it's often almost impossible to anticipate how they will be evaluated in another. In fact, making assumptions about implementation beyond what is expressed in the service contract violates the idea of loose coupling inherent in the SOA model. This is where it's going to get tricky.

If you look at the SAML specification for a moment, you will see that it makes provision for defining extent in time (as well as other conditions). As part of a claim, you can supply values for NotBefore  and NotOnOrAfter . These attributes of the Conditions element are optional, of course, as they should be to provide the flexibility to handle simple cases simply and more complex cases at all. But the formal specification isn't normative; it can only take you so far. Beyond that, the burden is on us to devise policies that comply with business, industry and regulatory requirements and then implement services and consumers with access controls that effectively support those policies. WS-Policy can help us express and advertise these in the services we build, but it won't drive agreement about the substance and specific constraints of access control policies. I'm suggesting that, while bounding access control conditions in space and time are optional in the specifications, they will often be mandatory for authorization claims when sensitive information is being exchanged. We will need to stabilize claims just as we need to stabilize other forms of data in highly distributed scenarios.

Stabilizing claims can help to solve the problem of revocation. By freshness-dating claims before they go out the door-as long as we also then evaluate the boundaries of these claims when we authorize a service request. Freshness dating milk only helps if you actually check the label before you drink it. Admittedly, doing this will complicate our claims-based authorization mechanisms, but as Einstein pointed out, we should keep things as simple as possible, but not simpler. Things could get further complicated for services that are subject to strict regulatory compliance or that deal with highly sensitive information. In these cases, we will need to forge agreement between service-providers and service-consumers regarding what constitutes adequate and reasonable tolerances for claims conditions-especially with respect to time. Token specifications appear to be rich enough to support such policy agreement, but they will be no help for defining the terms.

MSIT Eats Microsoft Dog Food and Thrives

Recently, I had an opportunity to meet several of the enterprise architects from Microsoft IT. After I published my article on Enterprise Authorization Strategy, I got to talking with Aaron Hanks about some of the challenges of enterprise authorization. Aaron has weighty architectural responsibilities addressing many of these challenges at MSIT. Last week, I spoke at TechReady5 and I had the opportunity to meet Gabriel Morgan and Nick Malik while I was out there in Seattle. They are also enterprise architects, and fellow denizens in Aaron’s building. Gabriel focuses on SaaS and Nick tends to focus on SOA in MSIT.  After meeting them, I got to thinking; you have to count this pack among the big dogs in enterprise architecture. Putting aside some of the most complex enterprise requirements they face for a moment, they have to eat more Microsoft dog food than just about anybody.

In case you’re not familiar with the term, dog food comes from the expression ‘eating your own dog food’ and refers to the act of using your own software, technology and solutions in-house. Of course, at Microsoft that often means pre-released dog food, too. In the local vernacular you can use it as a verb too. As in “you should dogfood this before you release it.” As you can guess, MSIT eats a lot of dog food.

There is architectural dog food too. It’s one thing to tout the virtues of SOA, SOI, SaaS, S+S and other sibilant acronyms on the lofty pages of MSDN; it’s quite another to actually solve real-world, day-to-day problems with this architectural approach, knowing that your company’s success depends upon it—in more ways than one. To me, MSIT is one place where the rubber has to meet the road. The requirements of governance, discovery, shared data schema, scalability, master data management and application portfolio management, for example, aren’t just theoretical exercises for architects at MSIT; they’re concrete issues that have to be addressed with practical solutions that work today.  You have to respect that. I do, anyway.

Btw, if you think MSIT is just a downstream consumer in the dog food chain, you would be wrong about that. When these dogs get hungry, they have been known to aggressively bare their requirements. If an enterprise requirement cannot be fully met with an existing product or technology, MSIT is frequently first to experience the agita.  When they drive these requirements back upstream to the product groups, they are effectively acting as a proxy for many of Microsoft’s enterprise customers who are facing similar challenges as well as for those of us in the field who work with these customers.

You shouldn’t kid yourself into thinking that MSIT has it easy because they only have to deal with a single, homogeneous platform and one vendor. Microsoft has some gravitas in the software business—to be sure—but it is also part of a much larger ecosystem of ISVs, partners, hardware, software and services vendors, contractors, financial institutions, manufacturing, hosting and network companies, packaging, shipping and distribution companies, VARS, and more. Like many large enterprises, Microsoft depends upon these business partners throughout the ecosystem for its continued success.  And guess what? As a group, they probably use every platform, system, wire protocol and data format on the planet. On a daily basis that means the big dogs at MSIT face very serious, enterprise-class challenges around interoperability, identity management, authorization, scalability, availability, content management, and telephony integration. Sound familiar? All of this and more exists in a highly heterogeneous, globally distributed ecosystem. If MSIT can devise a solution or architecture that works well on our platform in this environment, there’s a pretty good chance it will work well in your enterprise, too. Are you beginning to see where I’m going with this?

Hopefully, you’re beginning to come to the same conclusion I have. When MSIT architects have something to say, it is usually worth listening to. I’ve learned a lot from Aaron Hanks. Like: Be consistent, be persistent, speak softly and carry a big set of requirements. Nick Malik and Gabriel Morgan have great blogs that range over a wide array of enterprise architectural issues. Even if you don’t always agree, you usually find them interesting and thought provoking. I think you’ll also find that they generally understand the magnitude of the challenges in distributed computing in the enterprise today. Think you’re ready to run with the big dogs? Try the MSIT pack out for size.

Got SOC?

Good grief! Not another pesky TLA? Well, not really. SOC stands for service-oriented culture—an awkward term I use to describe a phenomenon that is an essential element of developing an SOA and sometimes conspicuously absent in the enterprise. Once I’d used this term a few times in my talks, my fellow evangelist and erstwhile cohort in crime, Allan  suggested I write a blog and take ownership of it.

A lot has been written to define what an SOA is, what its benefits are, and how to develop one. So much has been written in fact that the term ‘SOA’ may begin to suffer from what Jacques Derrida called effacement—the dissolution of meaning from overuse. Yet, as a wandering evangelist, I frequently find that SOA doesn’t have the momentum in the enterprise that one might expect given the honors that have been heaped upon it. I’ve started to think that the enterprise yearns for the virtues of SOA the way that Augustine of Hippo yearned for the virtue of chastity: “Grant me chastity and continence, only not yet.” I understand Augustine’s hesitation, but what about the enterprise? Why does the enterprise seem hesitant about the virtues of SOA?

Many organizations have overcome the inertia of the status quo and moved toward SOA with enthusiasm, of course—but many others are still moving forward at a snail’s pace—if at all. Even the enthusiasts won’t necessarily meet with immediate success on this front. And btw, having a bunch of services lying around your enterprise doesn’t constitute success with SOA, either. If you want to read a good article that keeps SOA in sharp focus, take a look at Control and Visibility in a Service-Oriented Architecture by my DPE colleague, Keith Pijanowski.

One factor that creates a drag on SOA adoption in the enterprise is a need for a well-organized and robust service-oriented infrastructure (SOI). Other factors at work hereare the trials and tribulations of attaining standardized, cross-platform service implementations. These can both be important obstacles to SOA adoption at times, but these factors have received a lot attention already; they’ll probably receive more in the future.  

One big reason for the sluggishness toward SOA that has been much neglected is the lack of service–oriented culture. SOA involves a true paradigm shift (Yes, I know this is a much hackneyed term—especially in information technology—but it’s very a propos here.) Part of every paradigm shift is a gradual process of cultural evolution. Paradigm shifts in computing are somewhat different from the scientific kind that Thomas Kuhn first described because they leave more room for doubt. When a new paradigm occurs in the scientific world, the shift has tremendous momentum because it provides superior explanatory and predictive power. Going from Newtonian to Einsteinian physics is a good example. Like a glacier, movement is slow but inevitable.

In the computing world, old paradigms often seem to have a strong inertia of their own, overlapping more broadly with the new paradigm. When N-tiered architecture appeared on the scene, for instance, client/server architecture and development continued largely undaunted for quite some time.  There are many reasons for this lagging effect, such as the lack of new tools, the need to fully leverage investment in the existing technology, the ramp-up time needed by developers to acquire new skills, and skepticism about the need for a new paradigm or its potential to fulfill its promise. But I think ‘cultural inertia’ is also fundamental to this phenomenon. Paradigm shifts push people and teams outside their psychological comfort zones—and this takes time.

Moreover, I think that this cultural inertia is greatly underestimated. The larger the community is, the greater the inertia can be—especially in risk averse organizations. Looked at from this perspective, the cultural factor helps demystify the sometimes torpid embrace of SOA in the enterprise.

In simplest terms, an SOC is the community mindset that has bought into the SOA paradigm. I’m not talking about the developer community alone. On the contrary, SOC must become pervasive in the IT community as well as business stakeholders in order to achieve the optimal benefits. Nor am I just talking about raising awareness about SOA, because success with this paradigm often requires far more. Ultimately, the development of an SOC may require an organization to transform itself in important ways. Architects and developers will need a new mindset and the skills to match it. The same is equally true for testing, deployment, infrastructure and operations. Each of these is a key facet of the community that must embrace service-orientated principles and fundamental change. Funding SOA can require fundamental changes to the budgetary process or new chargeback scheme’s to pay for services shared across multiple, semi-autonomous business units.

On the server side, an SOC may mean developing highly reusable services, but it also means designing facades that will position the business to take advantage of off-premise services as they become available. On the client side, an SOC can mean encouraging developers to fully leverage existing services in their designs and help drive new service requirements they are discovered. On the business side, SOC can mean coordinating joint development efforts between separate business units, being alert to opportunities to reduce cost or time-to-business value by consuming services in the cloud, or even providing services that can be securely accessed by partners or customers, improving business agility or opening new markets. In some cases, SOC will mean that parties from many different roles and areas of responsibility must work together to ensure that real interoperability across platforms is achieved with service and data contracts that actually model meaningful and useful business abstractions. Examples are abundant, but the point is that SOA must be ingrained in the culture throughout the enterprise.

Perhaps you will think I’ve gone too far by suggesting that business stakeholders are part of the SOC. Au contraire, mes amis!  Putting aside the obvious fact that transforming IT will require real business sponsorship and investment (i.e. money) to succeed, I think SOA is most powerful when it reflects service-orientation in the business architecture itself.  In fact, one could argue that many of the tenets of SOA were fundamental to business architecture long before they were introduced as the operative paradigm in IT. If you’re not convinced of this, I suggest you read Pat Helland’s superb article Metropolis –he’s not only more convincing, he’s more entertaining too. [Btw—it’s nice to see a card carrying member of the Barbarian Horde come back to Microsoft—for those who’ve been around long enough to get the reference.]

Surely, the tenets of contract- and policy-based design, service autonomy, and explicit boundaries are important fundamentals of business architecture as well as solution architecture. I would argue that SOA is most effective when business and IT are of like minds—that’s what an SOC is all about. It’s a shared commitment to a set of organizing principles. Business and IT can derive similar benefits from SOA—agility, standardization, adaptability to change, and quality of service, to name only a few. I really like Mohammad’s blog on this topic: Selling SOA to business stakeholders.