Application Scenarios and Solutions

As part of our patterns & practices Azure Security Guidance project, we’re starting off by focusing end-to-end application scenarios.  We’re taking a crawl, walk, run approach by starting with the simplest combinations of application types and authentication, authorization, and communication patterns.  This is the same Application Scenarios approach we used in Building Secure ASP.NET Applications.

This approach is helpful for mapping out a path and driving architectural spikes.  You can think of Application Scenarios and Solutions as what you would sketch on the whiteboard.  It’s a minimalist representation of the end-in-mind primarily focused on deployment and runtime patterns.  It’s about putting the Leggos together, before diving into the details (though the Devil is rumored to hang out there, and I’ve seen this first-hand.)

Example Application Scenario and Solution
The basic format is to show the Scenario, the Solution, and a Solution Summary Table.   The Scenario is a simple visual of the application from a deployment standpoint.  The Solution is a visual of how you might address authentication, authorization, and communication (the security runtime patterns.)  The Solution Summary Table is a quick description of how you would address the authentication, authorization, and communication from a security standpoint.

Here’s an example:

ASP.NET application on Azure.




Solution Summary Table

Area Notes
  • Authenticated with Forms authentication.
  • Authentication users with Forms Authentication.
  • Store users in Azure Tables.
  • Authenticate against user store through TableStorageMembershipProvider.
  • Database authenticates against the application identify.
  • Restrict access to resources using roles.
  • Store roles in Azure tables.
  • Use Role API provided by TableStorageRoleProvider.
  • Protect credentials over the wire with SSL.
  • Restrict access to Azure Storage by using a private key.

As you can see, it’s lean by design.  The idea is to put together a strawman of the solution so that we can first evaluate whether the direction even makes any sense.  This also lets us assemble many solutions pretty quickly so that we can chart out the potential paths and then pick the ones that make the most sense, and test them with customer feedback.

The next level down would be creating repros of the architectural spikes and creating step-by-step How Tos.  We’ve found this approach to be the fastest and most effective when it comes to sharing know-how.

Comments (0)

Skip to main content