imho Formal model based secruity

All:

Spellmaker: tzel

Spelltaker:
Remember the good old days when developers produced something called “programs”? The march of virtualization-—and of SOA-—has hastened the demise of “programs” as the basic unit of development, in favor of more diffuse constructs: models, patterns, and services. A little over a year ago, I wrote a column for Network World (http://www.networkworld.com/columnists/2004/090604kobielus.html) on this topic. Rather than attempt to paraphrase myself, I’ll simply quote myself, and pray that John Gallant and Susan Collins won’t ding me for reusing, at length and for no personal remuneration, content that I authored but their publication, technically, owns (and isn’t reuse the foundation of SOA-based blogging?):

************************

“SOA is a disruptive approach to building distributed services. Until now, we've developed new functionality on and within concepts such as platform, application and language. Each of these concepts has traditionally had a well-defined sphere of reference: The platform hosted the application, and the application was developed in a language. Now all that is changing, thanks to the emergence of SOA.

The first of the old computing concepts to wither away will be the platform. This term originally applied to operating systems, then included application servers that implement a particular development framework (Java 2 Platform Enterprise Edition or .Net) over one or more operating systems. But the growth of standards-based, distributed Web services has made it clear that fewer and fewer business processes will execute entirely within the confines of a J2EE 1.3 server or Windows Server 2003, or Linux, but will execute across them all. When all platforms share a common environment for describing, publishing and invoking services, the notion of self-contained platforms disintegrates in favor of SOA, which is essentially a platformless service cosmos.

Another casualty of this evolution is the notion of applications as discrete, functional components that execute on particular platforms. SOA is founded on the notion of virtualization. Under this paradigm, services describe abstract interfaces within standard, platform-independent metadata vocabularies such as WSDL. The underlying service functionality may be provided from components on any platform without needing to change the interface. Under SOA, the application dissolves into a service that may have no fixed implementation but simply bids for on-demand networked software and hardware resources.

Programming languages also are becoming something that fewer developers touch directly. Visual model-driven development and automated code generation are at the forefront of the SOA revolution. You're more likely these days to see a vendor boast of its ability to support visual modeling in Unified Modeling Language than development in Java, C# or any other declarative programming language. For complex, orchestrated, multiplatform Web services, visual modeling is the most effective approach for specifying, implementing and maintaining the end-to-end logic and rules on which the service depends.

SOA has spawned a range of terms to describe what developers actually develop. IT professionals increasingly define their creations in terms of services, models and patterns, rather than platforms, applications and languages. The notion of patterns will become critical to discussions of distributed services. A pattern is a generic approach - such as service proxying or service coordination - to architecting interactions in the infrastructure. Every pattern defines its own abstract Web services functional elements and SOAP-based interactions.”
************************

Where formal model-based security (yes, I've proofread the subject line, and am keeping the muse's original typo intact) is concerned, what are the dominant patterns? Can we even begin to discuss patterns in an area as all-encompassing and pervasive as security. Let’s limit our discussion to identity management (IdM). And, while we’re at it, limit it to federated IdM. If we accept that limited scope, the dominant patterns are defined by the use cases that a federated IdM environment addresses. Even then, we’ll need to spell out the dimensions of use cases, rather than enumerate the possible patterns themselves, because recombinant explosion, reflecting the diversity of real-world requirements and environments, defies our efforts to define off-the-shelf cookie-cutter federated IdM environments.

The principal elements of federated IdM models/patterns are, per the various use-case dimensions:

• Federation cross-domain topology: point to point, hub and spoke, decentralized, peer to peer
• Federation cross-domain transactional applications: identity, attribute, role, permission, and account provisioning; single sign-on; role-based access control; permission-based attribute sharing; digital rights management; secure messaging and collaboration; business process management; service management
• Federation middleware service layers: messaging, description, discovery, data management, metadata exchange, security, reliable messaging, event notification, pub/sub, transactions, orchestration, presentation, state/session management, service management
• Federation policy enforcement point deployment: intermediate systems, network perimeters, network endpoints
• Federation assurance levels: authentication assurance, credentials assurance, identity assurance, authorization assurance
• Federation governance: bilateral trust agreements; multilateral agreements

I’ve probably left out some important considerations. Regardless, any formal model of federated IdM security—or of security generally—needs to be built on such dimensions. Likewise, any model of the end-to-end set of compliance baselines that govern federations needs to mirror this multidimensionality.

Modeling’s the thing. Konceptual klarity uber alles. Mental acuity, model-based secruity.

Jim