Creating Secure Services, with Visual Studio Team Architect and the Web Service Software Factory Modeling Edition
Making secure is hard from a technology point of view. As Juval Lowy is saying in this MSDN article:
Security is by far the most intricate area of the Windows® Communication Foundation (WCF). In every WCF operation call on the service side, security is governed by the service contract, the operation contract, the fault contract (if present), the service behavior, the operation behavior, the host configuration, and the method configuration and its code. Each of these items may have as many as a dozen or more security-related properties...
And it's hard from a process point of view, also known as SD3+C. [The New Threat Modeling Process]
You must get executive support [not always that easy], you must create awareness, you must tackle the "not now we must make functionality" problem and some more.
Additional information can be found in these links.
- How Do They Do It? A Look Inside the Security Development Lifecycle at Microsoft
- The Trustworthy Computing Security Development Lifecycle
The The Security Development Lifecycle BLOG is a great place to start reading on this topic.
How to use Team Architect to make your SD3+C process more in control and help developers to build better, quicker secure services.
When you work with Team Architect you are already collecting innumerous information which can be used for threat modeling,
You've got the Logical Datacenter Diagram whit information about zones "Trust Boundaries" and servers which are in those zones. For example the Logical Datacenter Diagram below, We've got an internal legacy system with a broker in front which lives in a secure zone together with an some servers and internal clients, this zone exposes functionality through a DMZ to external clients and consumes information from an external creditcardserver. [forgive me the naming of the servers ;-)]
Probably / hopefully you are making this diagram together with the ITPro.
With the application diagram you start by defining the application design... [image]
...and map the applications to the Logical Datacenter with the Deployment Diagram [image], to do some deployment validation.
I Attended a LiveMeeting a while ago about quality tools and VSTS and one of the slides was this one, where the presenter [Adam Gallant] talked about infrastructure and deployment modeling as a quality tool. I completely agree with him.
anyway, the deployment diagram...
And now it gets interesting..!
We have a view of all or systems / applications and the zones they live in [Deployment Diagram, actually is should be called a Logical Deployement Diagram ;-]. It should be nice when we could model / configure at this level, in this deployment diagram, additional security information.
For example, we've got Internet connections, Intranet connections and Business-To-Business connections in this solution, just as Juval describes in his MSDN article. This isn't possible in Team Architect but, what we can do is create our own "security model"... just on other view point, where you can define security specific settings with the security manager.
So, what I did, I created a DSL with the zones, applications, connections and for each connection/ endpoint you can configure specific security settings.
When you add this model to your solution it takes all the necessary information out-of the Team Architect diagrams and creates the shapes. [still one challenge: layout... it doesn't organize the shapes. So you have to drag around the shapes to get a meaningful model]
This is how the security model looks like [image below, still needs allot of tuning].
It has all the applications, endpoints, connections and the zones. From this point the architect together with the security guy can start defining the specific security settings. By default every line is red and set to "No Security". When defining the type "Intranet - Internet - etc" of the connection the endpoints gets security specific properties like certificate store, certificate name, Impersonate and so on... and in the details window there is the ability to set at operation level detailed information, for example if one operation needs impersonation and another doesn't...
Note: this model is far from finished, actually it's just an implementation of a brainwave, to give it a try if it would work this way and to get some discussion going on about modeling viewpoints/ quality attributes.
Anyway, only the model isn't that interesting.
It gets more useful when the Web Service Software Factory ,attached to the application diagram, take notice of the security model and use it during code generation.
For the implementation I used Juval's "Declarative Security Framework" and tweaked the Service Factory T4 templates a little bit. Using the Framework is a little bit overdone, because we already have an easier way "raise the abstraction level" for security.
Another thing I'm working on, is [and you can see it in the solution explorer] the generation of an Thread and Analysis Model File [TAM].
This file is used by the Thread and Analyses Tool and helps people identify threads with in your solution. There is enough information in all the models to give threat modeling a jump start by providing this file... and not only helping the creation of secure service from a technology point of view but also from a process kind of view.
A nice way to embed Secure Development Lifecycle [SDL / SD3+C] into the Application Lifecycle [ALM]
Still a lot of work to do [I think most of my posts end with this sentence] but a nice start for discussion...
Reduce Project Risk: Get knowledge of the environment where the system operates.
One of the most “technical” challenging phase of a project is the transition of code from the development environment through the integration and test environments into production with Installer Packages.
Within most companies developers are responsible for the creation of Installer Packages. The MSI’s are created on development workstations, which have local admin rights and most often some exotic settings and applications. For sure, completely different than the production environment. With all the risks and extra work during deployment and testing.
In a more ideal situation, packages are automatically generated during the build process. A much better situation, but also harder to accomplish. The process is completely automated and can be reproduced. But still it doesn’t reflect the production environment, which still result in project risks.
When development doesn’t know and can’t test against real production environment settings we get some challenging risks.
For example how should we test non-functional requirements like: availability, scalability, capacity and performance? and how should development write installation instructions and operations guides (deployment, backup, recovery, weekly tasks) and probably there will be some problems with security and the configuration of security settings when deploying to production.
So, a better way should be when development knows the production environment details.
Operations can describe every detail about the environment, but, you also can use Team Architect’s Logical Datacenter Designer [LDD].
Logical Datacenter Designer is used to create models that describe the policies and logical structure of a datacenter, including servers, firewalls, communication paths, security constraints, and other configuration requirements that affect the deployment of application systems into a datacenter.
The Logical Datacenter Designer is a design tool..! so don't tease operations with Visual Studio, you will get the most strange reactions when you do that. You better could use the IIS Settings Import Wizard and ask for the credentials.
Anyway, finally you will end with a more "in control" deployment process.
Development knows the production environment, so they can design and build there applications with the real settings in mind. With this extra knowledge Design For Operations and Design For Deployment are much more realistic. Development can give operational management the right information how the solution need to be managed and monitored which will result in lower project risks..!
Some extra things we can do to automate this, "Enable ALM by Automation":
- Generate installer packages from the Logical Datacenter Designer, System Designer and Application Designer. We've got all the information we need! [see DSL 4 WiX]
- Generate MOM packages and manageability models [see Design for Operations on Codeplex and this post]
- Create WorkItems in TFS.
- Create Threat Models with the "Import Deployment Report" feature from the Microsoft Threat Analysis and Modeling Tool and create WorkItems from there.
- ...
some additional information:
- MSDN Virtual Lab: Architecting Connected Systems: Logical Data Center
- MSDN Virtual Lab: Architecting Connected Systems: System Designer
- Kevin Sangwell Blog: Bridging the Gap between Development and Production [very good information about this topic]
- Gearing Up for Modeling, Microsoft Style, April 01-2006
Rosario Team Architect Exposed, Getting Information Out Off the Designers.
I'm not fully up and running with the Rosario CTP, but found yesterday evening some time to dig into the internals of Team Architect. [Reflector rules]
Getting information out off the designers.
It is pretty hard to iterate through the various applications and endpoints within the VS2005 and VS2008 designers . You must load the .ad file with an XML reader and query it. Rosario makes this allot easier, it exposes methods to do this.
This is the Application Designer ToolAdapter Interface with the getApplications, getEndpoints, etc methods:
The new way to iterate the applications and endpoints. Much better than overly long XML queries:
Inside the "Rosario" Service Factory there are some helper classes to get the ISoaService
Update: removed the formatted code and added screenshots.
Mini-Stories for Visual Studio Team Edition for Software Architects, Rosario CTP10
Very useful, these mini-stories founded on the CTP10 desktop
- Walkthrough: Visualizing Interaction Sequences Between Service-Oriented Applications
- Walkthrough: Designing and Visualizing Classes and Their Interactions
- Walkthrough: Building Windows Communication Foundation Web Services Using Distributed System Designers and the Web Service Software Factory (WSSF)
From the "Stories"document [the interesting topics highlighted in red]:
In this CTP, you will find many new exciting features that help make design and development more productive. These features can be grouped in to two categories: factory integration and new integrated designers.
Factory integration starts with a base design experience in Visual Studio Team Edition for Software Architects, which applies to multiple application types. We then extend this experience for specific application types (Web client, smart client, and so on) using downloadable ‘factories’ supplied by the Patterns & Practices group at Microsoft. These factories provide a guided design experience based on best practices that accelerate enterprise design and development using the Microsoft platform. A pluggable architecture allows these factories to be shipped continuously on the Web so you can continue to receive the latest design guidance between major releases of Visual Studio. In this CTP, we’ve already downloaded and installed a factory for building Web-based applications based on WCF to demonstrate one specific application type (Web Services Software Factory).
To better enable a wider range of design experiences, in this CTP we have added two new designers “in the box.” The sequence designer allows you to model the interaction of services or objects in your application. This is very useful as a design tool to help you define how your application will fulfill the requirements of your solution. Using this designer, you can identify important classes and services and make sure that they have the correct operations to support your scenarios. In addition, we have added a logical class designer to complement the existing physical class designer. This designer lets you reason about class design before committing to an implementation and enables you to model relationships not possible just by using the physical class designer. Most importantly, these two designers are integrated so that changes in one designer naturally flow to the other to keep your models synchronized and support accurate code generation and discovery in future CTPs.
So I played with it [not heavy, still quite busy with Orcas], I recreated the models from our original project
First the application designer:
I still think to many shapes that don't belong there [the red ones].
The Application Explorer:
I really like it it's called "ServiceContractDiagramViewpoint"... see this post about viewpoints.
The Sequence Designer:
I have to play a little bit more with this one... looks / works create maybe the shapes should have the same color as they have on the Application Designer [not that important].
Anyway, more details will follow...
The Three Most Interesting Features in Team Architect "Rosario"
1: The Designer Bus,
No documentation about this yet.
It makes integration of models allot easier. For example the integration between the Application Diagram and the Service Models or the Sequence Diagrams.
2: Using the Distributed System Designers and the Web Service Software Factory to build WCF applications.
Very nice :-)
There are new WSSF items in your Toolbox from where you can design services and there are parts of the Team Architect Powertool used to visualize implementation details.
I'm not a big fan of the PowerTools, a reasons is that there will be to much shapes on you design surface and classes / assemblies have a different level [lower] of abstraction than applications... I used it a for a while but stopped with it, Anyway, I give it a try in this CTP...
3: Visualizing Interaction Sequences between Service-Oriented applications.
This has some really added value when designing distributed systems..!
When you take a look at the document "Evaluating a Service-Oriented Architecture" from the SEI you can find this page, design and document a Service-Oriented Architecture with: a component and connector diagram [application diagram] and sequence diagrams...
For more details: Jeff Beehler's Blog: November Rosario CTP now available!
Download location:Visual Studio® Team System Code Name "Rosario" November 2007 CTP VPC Image
Documentation: Visual Studio Team System Code Name "Rosario" November 2007 CTP Documentation
Autonomous Develop Services for SOA Projects with Team Architect and Service Factory
In an ideal "SOA" world, business-services have a business driver or at least some one from the business who is responsible for it [knows something about the data and operations that service exposes] and has information who is consuming, is going to consume the service and who is allowed to consume. With that, takes the initiative to ask the development department to make that business-service.
The real "SOA" world: the business thinks in GUI's and not in services. So, they ask for applications and let the decision which service to make to the development department. 
That's no problem, till more and more applications are going to be build and more and more services are created.
For example the first application needs customer data. So, this project team start with the creation of a customer-service. Meanwhile an other request for an application enters the development floor, which also needs to consume customer data.
Two situations can occur:
- The project-managers from the different projects are getting a fight about who is responsible [budget] for the creation of that service. Projects will wait for each other till there is a compromise and peace. You have been chosen to be the Deadlock victim..! [I like that SQL Server message].
- The different projects both create their own customer-service. Bad, bad solution... but very common in the real world.
A solution...
It's the responsibility off the development department to define, create and deploy services, also when the business defines them it's the development department's responsibility to take control in this process.
So, what should be a solution from a development point of view.
- Make Partitioned Solution Structures..!
See "Solution Explorer" image, this is a normal solution structure. I think you can see what kind of problems we get when an other project also needs the customer-service.We got a deadlock for this project, they have to wait till this project finished the development of this service or they have to make one them self.
With a Partitioned Solution [image below and links a the bottom] you're using multiple solutions, each representing a sub-system in your application. So, each service will have his own "solution". Developers can focus on this single service-project and this service-project should have his own build and TFS project environment. So, if the business won't separate them... we do it our self!
.gif)
- Although we are making a Partitioned Solution structure, there is still a challenge left... What about projects who need that service and are also under development? this is where Team Architect can help [see image]
With Team Architect you can model your systems and define the endpoints operations and types. So, when we define all this service provider information the consumers also know what kind of operations and types they can expect. With that we can generate some basic implementations for the service agents.
What will happen when there is an other project which will consume a service in this project... just add it.
With the Service Factory we have control in which way the projects are created.
In the "Master" solution I let it create only the models and on the background it creates the "Partitioned" solutions, with the project specific models from where the development of that services can continue.
[At this moment I create for every endpoint service provider and consumer a separated model, I think this will change... for the provider "service contract" model that's fine but for the service agents I'm going to change it to one model per service instead of per endpoint]
[The solutions]
[The single service project. the good thing is that the master solution still is in control about the operations and types this service exposes, so all the agents are updated automatically]
[The service agent, which will generate a mock / stub for service in development and a real service proxy for existing services]
Still some challenges ahead but I think it's in the right direction [any comment?].
Anyway, time to look for Microsoft Visual Studio Team System code name "Rosario" November 2007 CTP, Rob Mensching just published a post that it will be released today [pacific time] and more important it will have a WiX Toolset. [good job..!]