J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

  • J.D. Meier's Blog

    Lessons Learned from Per


    I like to learn from everyone around me.  One of my most influential mentors has been my manager, Per.  Here’s a highlight of some of the lessons I learned from Per over the years:


    • Consolidate communication.   Chunky over chatty.  Rather than a random stream of ideas, consolidate down to a theme.  Rather than a bunch of mini-mails, consolidate to a more meaningful message. 
    • Distinguish between phases of communication.  Walt Disney used three stages for ideas: Dreamer, Realist, and Critic.  Dreamer is the vision, Realist is the steps, Critic is the constraints and limits.  In practice, Per encourages first brainstorm, then critique.

    Cutting Questions

    • Do you influence or do you own?   Distinguish between when you own the decision versus when you influence.  If you influence, but don’t own, reset your own expectations.  Responsibility without authority is a common pitfall. 
    • Does it matter?   In the grand scheme of things, does this particular issue matter.
    • Five customers under your belt?  If you don’t have five customers you can point to that stand behind what you’re doing, it’s a flag.  As simple as this test sounds, I’ve used it many times to ensure project success.
    • Is it the right thing to do?  First figure out the right thing to do, then figure out what you can do based on the circumstances.
    • Is it working?  If you keep taking the same approach, but it’s not working, you need to change your approach.  It’s simple, but you’d be surprised how many people get stuck.
    • Next steps?   Asking “next steps?” at the end of your meeting is a pretty crisp way of turning talk into action.
      What’s the agreement?  When you’re not sure why things aren’t happening as you expect, check the agreement.  You might find you don’t really have one.
    • What’s the solution?  If you’re spending too much time on the problem, switch by asking, “what’s the solution?”
    • What’s their story?  If you don’t get why another person or team isn’t doing what you want, figure out what their side of the story is.  (see What’s Their Story)
      What’s your gut say?  If you find a decision isn’t sitting right, check your gut.   While the numbers may say one thing, your intuition may be telling you a deeper story.


    • Argue the data.  Rather than argue your opinion, argue the data.  Arguing the data keeps it more objective.  It can also be more convincing.
    • Don’t state the conclusion.  Rather than state your conclusions, show the data that leads to your conclusions.  Even if you know the “right answer,” showing the data can help others get on board.
    • Lead the horse to water.   Let them connect the dots.  You can draw a dotted line, but let your audience connect the dots. 
      Mental Judo.  This is Per’s phrase for Ward Cunninham’s uncanny ability to lead people to a conclusion through rhetoric and stories.
    • Set the frame.   Frame the problem or solution so that you have a common backdrop to share understanding.  This will help set boundaries, create agreements, and improve communication.
    • They’re not engaged.  If you notice a lack of engagement throughout your meeting, there’s a good chance that you don’t have rapport.  If you don’t have rapport, you won’t effectively influence.
    • They’re not on board.  You should be able to tell whether somebody is on board.  If they aren’t, then don’t kid yourself.
      You didn’t agree on values.  Recognize when you don’t have the same values.  Do they value time or do they value a level of results?  If you don’t share the values, you can expect problems in agreements, prioritization, expectations, and results.
    • You didn’t have buy in.  Just because somebody shakes their head yes, doesn’t mean they are bought in.  You don’t want somebody to tell you yes, just to drag their feet.

    Organizational Prowess

    • Call it an experiment.  In a risk adverse environment, it can help to call a project an experiment.  It’s a simple but effective metaphor to help people think about trying something new.
    • Do you influence or do you own?  If you don’t own the decision, you don’t own it.  Period.  You can attempt to influence, but at the end of the day, you’re not the owner.   That doesn’t mean don’t try your best.  Just don’t be surprised if it’s not the decision you wanted and don’t take it personally.
    • Expose the approach.   People may not agree on the implementation or the results, but sharing the approach is a good place to start.  Exposing the approach gives you a chance to improve the approach.  Exposing the approach can also build trust, particularly if everybody buys in.
    • Expose the thinking.  This is similar to showing your homework.  If you expose the thinking, then you can improve the thinking.  You can also help build trust.  You may not get to the right answer, but showing how you got there helps bring people along with you.
    • Get consensus.  Where possible and time permits, get folks on board.  If there’s resistance, this can be a flag that you’re off in the wrong direction.  If it’s a decision where you need everybody’s skin in the game, then you’ll want them on board helping push the ball forward versus dragging their feet.
    • Get smart folks on the bus.  This is just a general belief that if you have smart people around, the right things will happen.  It’s about people over process.
    • Slides are a forcing function.    Slides are a great way to get folks on the same page, or at least start the dialogue.  If you can’t show your ideas in a slide, then you don’t have a well-formed message for others.  Doing slides helps create a strawman of the thoughts that can be reviewed and improved.  Slides can help turn thoughts into action.


    • Change your approach.  If it’s not working; change your approach.
    • Change yourself first.  You can change yourself faster than you can change others.  Seriously.
    • Chunk it down.   If you can’t release something in a healthy rhythm, chunk it down.
    • Divide and Conquer.  If you have an overwhelming challenge, divide and conquer.(See Divide and Conquer - One Step at a Time)
    • Drive or Be Driven.  If you don’t drive it, you’ll be driven by somebody else.
      Get it out and get feedback.  Good ideas often die because there’s no action or momentum.  If you get something out, you can get feedback and start to improve it.
    • Give attribution.  In our industry, acknowledgement is important.  Be sure to give attribution where it’s due.
    • Focus.   If there’s one place where projects fail or people fail, it’s a lack of focus.  Focus is your friend.  If you’re not getting results, narrow the focus. 
    • Follow your passion.  Where there’s passion, there’s strength.
    • Forcing functions.  Use meetings, slides, and reviews as forcing functions to drive results.
    • Model the best.   This is Per’s phrase for my approach of finding the best people and modeling their success. 
    • Play to your strengths.  Per’s a fan of the book, Good to Great, and he believes in focusing on your strengths rather than your weaknesses.
    • Rattle the cage.  Challenge the thinking.  Challenge ideas.  Challenge yourself.  Don’t fall into the trap of the status quo.
    • Ship it!  This is one of Per’s favorite sayings which characterizes the emphasis on getting results and making impact.   He’s learned that a rhythm of shipping produces results while failure to ship is how teams fail at Microsoft. 

    My Related Posts

  • J.D. Meier's Blog

    Project Life Cycles at patterns & practices


    Periodically I like to revisit our project life cycle in patterns & practices. I like to see how it's shape-shifted over the years.  (Note - our project life cycle wraps our product cycle)  

    patterns & practices Project Life Cycle Circa 2005
    Here's a snapshot of our patterns & practices project life cycle circa 2005:


    I used this as a baseline to reflect against.  Here are the phases, stages, and milestones:

    Projects cycled through the following phases:

    • Planning
    • Design
    • Implementation
    • Stabilization
    • Release

    Stages included:

    • Requirements
    • Specifications
    • Iteration 1
    • Iteration N
    • Final Test and Edit Pass
    • Production

    The milestones included:

    • Proposal Approved
    • Vision Scope Approved
    • M0 (Milestone Zero) / Specifications Approved
    • Technical Review and Solution Approved
    • Test and Edit Complete
    • Go / No Go
    • Customer Availability

    Three Things That Worked Well
    Here's three things that worked well with the original project cycle:

    • There were clear phases, stages, milestones, and deliverables, along with criteria.
    • The project cycle was decoupled from the product cycle.  This gave management a simple frame for understanding projects.  This also gave each project flexibility to choose the most appropriate software development methodology depending on the product.
    • There was sufficient time between key milestones to provide a frame + air-cover.  This helped avoid randomizing engineering and being able to see the forest from the trees.

    Additionally, the key milestones such as Vision Scope and MO were something of a ceremony and tended to include the right representation across the p&p team.

    Three Things That Needed Improvement
    Here's three things that needed improvement:

    • It was a lot of overhead for smaller projects.  It worked well for larger programs (collections of projects), but it was tougher for individual projects.
    • It was tough to bootstrap projects.  M0 and Vision/Scope could be especially tough.  In retrospect, there were two key issues: 1) asking the right questions at the wrong time (premature) 2) chickens with controlling votes over pigs. (See Turning Chickens Into Pigs.)
    • There was too much agreement up front, with not enough ability to coarse correct in the later stages/phases (needed more agility)
  • J.D. Meier's Blog

    Model-Driven Approaches


    When people ask me my take on model-driven approaches, I think of two ends of the spectrum -- human and the machine.

    Key Points 

    • Model for humans.  For humans, I find using a whiteboard (whiteboard modeling) works well -- it's universal.
    • Model for machines.  For machines, I find speaking closer to the code is a good thing and design is rarely a clean model.
    • Model to learn.  I've found modeling more useful when you throw it away -- it's a learning tool.  Model so you get it, then go to it.  I think the key is that the model is a map, not the actual territory.  The usefulness of a map is actually decoupling from the complexity and creating a simpler lens.
    • Model to share.  I think the real value of models is when you create a way to share the problem or solution in a simplified way.  This helps for sharing a vision of the end in mind, as well as getting more sustained thinking around the problem.

    Model-Driven Code
    I've never experienced an effective modeling approach that turns visuals of systems into code, where the model doesn't get in the way.  At some point, the model stops being useful for humans or stops being useful to the machine.  As a result, I've never really been a fan of model-driven approaches that are coupled to code in practice, although they're always interesting in theory.   While I'm open to the idea, I just haven't seen it.  Am I missing out?

    Effective Modeling for Shaping Software
    While I'm not a fan of most visual modeling tools, there’s some very real modeling approaches I find to be effective (which is more about modeling for the humans to understand what matters.)  I find that light-weight, human-oriented models are particularly effective for shaping software around quality attributes.  For example:

    My Related Posts

  • J.D. Meier's Blog

    Agile Guidance


    When I ramp new folks on the team, I find it helpful to whiteboard how I build prescriptive guidance.  Here's a rough picture of the process:


    I've used the same process for Performance Testing Guidance, Team Development with Visual Studio Team Foundation Server, and WCF Security.

    Here's a brief explanation of what happens along the way:

    The dominant focus here is identifying candidate problems, candidate solutions, and figuring out key risks, as well as testing paths to explore.  The best outcome is a set of scenarios we can execute against.

    • Research - finding the right people, the right problems, and the right solutions.
    • Prototypes - experiment and test areas of high risk to prove the path.  This can include innovating on how we build prescriptive guidance.  We also use these to test with customers and get feedback on the approach.
    • Question Lists - building organized lists of one-liner user questions.
    • Task Lists - building organized lists of one-liner user tasks.
    • Scenario Frames - organizing scenarios into meaningful buckets.  See Scenario Frame Example.
    • Information Models - framing out the problem space and creating useful ways to organize, share, and act on the information.  See Web Services Security Frame.
    • Guidance Types  - testing which guidance types to use (how tos, checklists, guidelines, patterns, ... etc.)

    The dominant focus here is product results.  It's scenario-driven.  Each week we pick scenarios to execute against.

    • Development - building prescriptive guidance, including coding, testing, and writing.
    • Backlog - our backlog is a prioritized set of scenarios and guidance modules.
    • Iterations - picking sets of scenarios to focus development on and test against.
    • Refactoring - tuning and pruning the guidance to improve effectiveness.  This includes breaking the content up and rewriting it.  For example, a common refactoring is factoring reference information from action.  We try to keep reference information in our Explained modules and action information in our How Tos.
    • Testing -  step through the guidance against the scenario.  The first pass is about making sure it works.  It should be executable by a human.  Next, it's about reducing friction and making sure the guidance really hits the what, why and how.  We test the guidance against objectives and scenarios with acceptance criteria so we know when we're done.
    • Problem Repros - creating step by step examples that reproduce a given problem.
    • Solution Repros - creating step by step examples that reproduce a given solution.

    We produce a Knowledge Base (KB) of guidance modules and a guide.  The guidance modules are modular and can be reused.   The guide includes chapters in addition to the guidance modules.  Here's examples from our WCF Security Guide:

    Agile Publishing
    We release our guidance modules along the way to test reactions, get feedback and reshape the approach as needed.

    • CodePlex - we publish our guidance modules to CodePlex so we can share early versions of the guidance and get customer feedback, as well as to test the structure of the guidance, and experiment with user experience.
    • Guidance Explorer - we publish guidance modules to Guidance Explorer so users can do their own guidance mash ups and build their own personalized guides.  Our field also uses this to build customized sets of guidance for customers.

    Stable Reference
    Once we've tested and vetted the guidance and have made it through a few rounds of customer feedback, we push the guidance to MSDN.

    • MSDN - this is the trusted site that users expect to see our prescriptive guidance in final form.
    • Visual Studio/ Visual Studio Team System - once we're a part of the MSDN distribution, we can automatically take advantage of the VS/VSTS documentation integration.

    My Related Posts

  • J.D. Meier's Blog

    Software Guidance Share


    I'm testing another version of the home page on Software Guidance Share.  Software Guidance Share is a perpetual work in progress.  I think of it as my quick-and-dirty guidance KB for developers and solution architects.  I continuously refactor information into reusable nuggets.  I also test ways to browse the guidance and find relationships among the nuggets.

    Here's a couple of example scenarios:

    I haven't fleshed out some of the areas, but the Wiki gives me a lot of flexibility and it's easy to course-correct.  In other words, it's more adaptable than adapted.

  • J.D. Meier's Blog

    Designing an Authentication and Authorization Strategy


    What are the key steps to designing an effective authentication and authorization strategy?  The keys are knowing your user stores, role stores, and who need to access what or perform which operations.   In this post, I share the approaches we've used in two of our patterns & practices guides.  These are the approaches we've used to help customers design successfully design their authentication and authorization approaches.

    Designing an Authentication and Authorization Strategy - v1
    When we first wrote Building Secure ASP.NET Applications, here's the meta-process we came up with for working through your authentication and authorization strategies:

    1. Identify resources
    2. Choose an authorization strategy
    3. Choose the identities used for resource access
    4. Consider identity flow
    5. Choose an authentication approach
    6. Decide how to flow identity

    For elaboration, see Authentication and Authorization.

    Designing an Authentication and Authorization Strategy - v2
    When we recently wrote Improving Web Application Security, we made some revisions:

    1. Identify your user stores.
    2. Identify your role stores.
    3. Identify resources you need to access and operations you need to perform.
    4. Identify which identities need to access the resources and perform the operations.
    5. Choose your authentication and authorization strategies.

    Personally, I've found it really cuts to the chase if you start with your user stores and role stores, since they tend to be somewhat fixed. 

    When you think through the identities, I've found it helpful to think in terms of who needs to access which resources or perform which actions.  Consider the following:

    • Original caller
    • Process identity
    • Service account
    • Custom identity
    • Role

    Resource Types
    When you think through the resource types, I find it helpful to think in terms of:

    • System
    • Application
    • User

    Authorization Strategies
    When thinking through the authorization strategies, I find it helpful to consider:

    • Role-based
    • Resource-based
    • Operation-based

    Resource Access Patterns
    When thinking through the resource access patterns, I find it helpful to consider:

    • Trusted subsystem model
    • Impersonation/delegation model

    Designing authentication and authorization can be a gnarly topic.  I hope the scaffolding above helps you find a path that works for you.

  • J.D. Meier's Blog

    WCF Security Guide is Now Available in HTML


    Our guide, patterns & practices Improving Web Services Security:Scenarios and Implementation Guidance for WCF is now available in HTML.

  • J.D. Meier's Blog

    New Release: patterns & practices WCF Security Guide (BETA)


    Today we released our WCF Security guide, patterns & practices Improving Web Services Security: Scenarios and Implementation Guidance for WCF.  This is our Microsoft playbook for Windows Communication Foundation (WCF - "Indigo".)  It shows you how to build secure Web services using WCF.  It's a compendium of proven practices, product team recommendations and insights from the field.

    Download the guide

    Contents at a Glance

    • Part I, "Security Fundamentals for Web Services"
    • Part II, "Fundamentals of WCF Security"
    • Part III, "Intranet Application Scenarios"
    • Part IV, "Internet Application Scenarios"


    • Ch 01 - Security Fundamentals for Web Services
    • Ch 02 - Threats and Countermeasures for Web Services
    • Ch 03 - Security Design Guidelines for Web Services
    • Ch 04 - WCF Security Fundamentals
    • Ch 05 - Authentication, Authorization and Identities in WCF
    • Ch 06 - Impersonation and Delegation in WCF
    • Ch 07 - Message and Transport Security in WCF
    • Ch 08 - WCF Bindings Fundamentals
    • Ch 09 - Intranet – Web to Remote WCF Using Transport Security (Original Caller, TCP)
    • Ch 10 - Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem,HTTP)
    • Ch 11 - Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem TCP)
    • Ch 12 - Intranet – Windows Forms to Remote WCF Using Transport Security (Original Caller, TCP)
    • Ch 13 - Internet – WCF and ASMX Client to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)
    • Ch 14 - Internet – Web to Remote WCF Using Transport Security (Trusted Subsystem, TCP)
    • Ch 15 - Internet – Windows Forms Client to Remote WCF Using Message Security (Original Caller, HTTP)


    • WCF Security Checklist
    • WCF Security Guidelines
    • WCF Security Practices at a Glance
    • WCF Questions and Answers (Q&A)
    • How Tos
    • WCF Security Resources

    Contributors and Reviewers

    • External: Andy Eunson; Anil John; Anu Rajendra; Brandon Bohling; Chaitanya Bijwe; Daniel Root; David P. Romig, Sr.; Dennis Rea; Kevin Lam; Michele Bustamante; Parameswaran Vaideeswaran; Rockford Lotka; Rudolph Araujo; Santosh Bejugam
    • Microsoft: Alik Levin; Brandon Blazer; Brent Schmaltz; Curt Smith; David Bradley; Dmitri Ossipov; Don Smith; Jan Alexander; Jason Hogg; Jason Pang; John Steer; Marc Goodner; Mark Fussell; Martin Gudgin; Martin Petersen-Frey; Mike de Libero; Mohammad Al-Sabt; Nobuyuki Akama; Ralph Squillace; Richard Lewis; Rick Saling; Rohit Sharma; Scott Mason; Sidd Shenoy; Sidney Higa; Stuart Kwan; Suwat Chitphakdibodin; T.R. Vishwanath; Todd Kutzke; Todd West; Vijay Gajjala; Vittorio Bertocci; Wenlong Dong; Yann Christensen; Yavor Georgiev
  • J.D. Meier's Blog

    Web Services Security Frame


    The key to making principles, patterns, and practices more effective is to have an organizing frame.  While working on our patterns & practices WCF Security Guidance Project, we created the Web Services Security Frame for just such a purpose.  We use the frame throughout the guidance to organize threats, attacks, vulnerabilities and countermeasures, as well as to organize principles, patterns, and practices. 

    Web Services Security Frame

    Here's a snapshot of the frame (the power of the frame is that it's a durable, evolvable backdrop -- in other words, you can shape it to your own purposes.)  You'll see this frame used throughout our upcoming guide.  Notice that the categories serve as a pivot that we can hang other viewpoints (threats/attacks, vulnerabilities, countermeasures.)

    Category Description
    Auditing and Logging Auditing and logging refers to how security-related events are recorded, monitored, and audited.
    Authentication Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password.
    Authorization Authorization is how your service provides access controls for resources and operations.
    Configuration Management Configuration management refers to how your service handles database connections, administration and other configuration settings.
    Exception Management Exception management refers to how you handle exceptions within your application, including fault contracts.
    Impersonation/Delegation Impersonation and delegation refers to how your service impersonates users and passes identity information downstream for authorization purposes.
    Message Encryption Message encryption refers to protecting a message by converting the contents to cipher-text using cryptographic methods.
    Message Replay Detection Message replay detection refers to identifying and rejecting messages that are re-submitted.
    Message Signing Message signing refers to signing a message with a digital signature using cryptographic methods, to confirm the source of the message and detect if the contents have been tampered with (i.e. authentication and integrity of the message.)
    Message Validation Message validation refers to how you verify the message payload against schema, as well as message size, content and character sets. This includes how your service filters, scrubs and rejects input and output before additional processing. Input and output includes input from clients consuming the service as well as file-system input, as well as input from network resources, such as databases. Output typically includes the return values from your service or disk / database writes among others.
    Sensitive Data Sensitive data includes data integrity and confidentiality of your user and application data that you need to protect. This includes how you protect sensitive data from being stolen from memory, from configuration files or when transmitted over the network.
    Session Management A session refers to a series of related interactions between a client and your service.


    Threats / Attacks Organized By the Web Services Security Frame


    Category Threats / Attacks
    Auditing and Logging
  • Repudiation
  • Denial of services
  • Disclosure of confidential information
  • Authentication
  • Network eavesdropping
  • Brute force attacks
  • Dictionary attacks
  • Cookie replay attack
  • Credential theft
  • Authorization
  • Elevation of privilege
  • Disclosure of confidential data
  • Data tampering
  • Luring attacks
  • Token stealing
  • Configuration Management
  • Unauthorized access to configuration stores
  • Retrieval of clear text configuration secrets
  • Exception Management
  • Information disclosure
  • Denial of service
  • Elevation of privilege
  • Impersonation/Delegation
  • Elevation of privilege
  • Disclosure of confidential information
  • Message Encryption
  • Stealing sensitive data.
  • Theft of encryption keys.
  • Man in the middle attack.
  • Message Replay Detection
  • Session replay
  • Message Singing
  • Data tampering.
  • Message Validation
  • XPath injection
  • XML Bombs
  • Canonicalization issues
  • Cross-site scripting
  • SQL injection
  • Sensitive Data
  • Memory dumping
  • Network eavesdropping
  • Configuration file sniffing
  • Session Management
  • Session hijacking
  • Session replay
  • Man in the middle attack
  • Inability to logout successfully
  • Cross-site request forgery
  • Session fixation
  • Load balancing and session affinity

    Vulnerabilities Organized by the Web Services Security Frame


    Category Vulnerabilities
    Auditing and Logging
  • Failing to audit failed logons
  • Failing to secure log files
  • Storing sensitive information in log files Failing to audit across application tiers Failure to throttle log files
  • Authentication
  • Using weak passwords
  • Storing clear text credentials in configuration files
  • Passing clear text credentials over the network
  • Permitting prolonged session lifetime
  • Mixing personalization with authentication
  • Using weak authentication mechanisms (For example, using basic authentication over an untrusted network.)
  • Authorization
  • Relying on a single gatekeeper (e.g. relying on client-side validation only)
  • Failing to lock down system resources against application identities
  • Failing to limit database access to specified stored procedures
  • Using inadequate separation of privileges
  • Permitting over-privileged accounts
  • Configuration Management
  • Using insecure custom administration interfaces
  • Failing to secure configuration files on the server
  • Storing sensitive information in the clear text
  • Having too many administrators Using over-privileged process accounts and service accounts
  • Exception Management
  • Failing to use structured exception handling (try/catch)
  • Revealing too much information to the client
  • Failure to specify fault contracts with the client
  • Failure to use a global exception handler
  • Impersonation / Delegation
  • Failure to revert to a lower privilege after using impersonation
  • Improper use of global impersonation across the entire service
  • Message Encryption
  • Failure to encrypt messages
  • Using custom cryptography
  • Distributing keys insecurely Managing or storing keys insecurely
  • Message Replay Detection
  • Failure to implement message replay detection feature
  • Message Signing
  • Unsigned messages that don't confirm the source
  • Unsigned messages that don't detect tampering
  • Message Validation
  • Using non-validated input used to generate SQL queries
  • Relying only on client-side validation Using input file names, URLs, or user names for security decisions
  • Using application-only filters for malicious input Looking for known bad patterns of input
  • Trusting data read from databases, file shares, and other network resources
  • Failing to validate input from all sources including cookies, SOAP headers, SOAP parameters, databases, and network resources
  • Session Management
  • Passing session identifiers over unencrypted channels
  • Permitting prolonged session lifetime Having insecure session state stores
  • Placing session identifiers in query strings

    Countermeasures Organized by the Web Services Security Frame


    Category Countermeasures
    Auditing and Logging
  • Identify malicious behavior.
  • Know your baseline (know what good traffic looks like)
  • Use application instrumentation to expose behavior that can be monitored
  • Throttle logging
  • Strip sensitive data before logging
  • Authentication
  • Use strong password policies
  • Do not store credentials in an insecure manner
  • Use authentication mechanisms that do not require clear text credentials to be passed over the network
  • Encrypt communication channels to secure authentication tokens
  • Use HTTPS only with forms authentication cookies
  • Separate anonymous from authenticated pages
  • Using cryptographic random number generators to generate session IDs
  • Authorization
  • Use least privilege accounts.
  • Authentication tied to authorization on the same tier
  • Consider granularity of access
  • Enforce separation of privileges
  • Use multiple gatekeepers
  • Secure system resources against system identities
  • Configuration Management
  • Use ACLs.
  • Encrypt sensitive sections of configuration files
  • Use secure settings for various operations of web services using configuration files
  • Exception Management
  • Use structured exception handling (by using try/catch blocks)
  • Catch and wrap exceptions only if the operation adds value/information
  • Do not reveal sensitive system or application information
  • Implement a global exception handler
  • Do not log private data such as passwords
  • Impersonation / Delegation
  • Use Using statement to automatically revert impersonation
  • Granularly impersonate only those operations that need it
  • Message Encryption
  • Use message security or transport security to encrypt your messages
  • Use platform-provided cryptography
  • Use platform features for key management
  • Periodically change your keys
  • Message Replay Detection
  • Cache an identifier for incoming messages, and use message replay detection to identify and reject messages that match an entry in the replay detection cache
  • Message Signing
  • verify messages have not been tampered with in transit (data integrity)
  • verify messages originate from the expected sender (authenticity)
  • Message Validation
  • verify the message payload against schema
  • verify the message message size, content and character sets
  • filter, scrub and reject input and output before additional processing
  • Sensitive Data
  • Do not store secrets in software
  • Encrypt sensitive data over the network
  • Secure the channel
  • Encrypt sensitive data in configuration files
  • Session Management
  • Partition site by anonymous, identified, and authenticated users
  • Reduce session timeouts
  • Avoid storing sensitive data in session stores
  • Secure the channel to the session store
  • Authenticate and authorize access to the session store
  • Thanks
    Special thanks to Rudy Araujo and ACE Team members, Richard Lewis and John Steer for their contribution toward helping shape a better frame.

    My Related Posts

  • J.D. Meier's Blog

    WCF Security Resources


    If you're building Web services or if you're implementing SOA on the Microsoft platform , then you're probably either working with or exploring WCF (Windows Communication Foundation.)   When we started our patterns & practices WCF Security Guidance project, one of the first things I did was compile a list of WCF security resources for our team.  This helped us quickly ramp up and as well as see gaps.  One thing that surprised me is how much is available in the product documentation, if you know where to look.  Here's a preliminary look at our WCF Security resources index which we'll include in our WCF Security Guide: 

    Getting Started













    Documentation (MSDN Product Documentation)




    Threats and Countermeasures


    How Tos






    patterns & practices

    Product Support Services (PSS)





    Web Casts

    MSDN Support WebCasts

  • J.D. Meier's Blog

    patterns & practices WCF Security Practices at a Glance Now Available


    For this week's release in our patterns & practices WCF Security Guidance project, we released our first version of our WCF Security Practices at a Glance.  Practices At a Glance gives you a bird's-eye view of how to perform common tasks.  They are scannable and outcome-driven so that you can quickly browse the problem/solution pairs.  Rather than a laundry list of granular tasks, we organize them by our Web Services Security frame (still evolving.)

    Here's how we grouped our WCF Security Practices at a Glance so far:

    • Auditing and Logging
    • Authentication
    • Authorization
    • Configuration Management
    • Deployment Considerations
    • Exception Management
    • Hosting
    • Impersonation/Delegation
    • Input Validation
    • Message Security
    • Proxy Considerations
    • Sensitive Data
    • Transport Security

    Here's a snapshot of the problems solved from our Practices At a Glance, but you can see our answers explained at our WCF Security Guidance project site.

    Auditing and Logging

    • How to audit authentication events
    • How to audit authorization events
    • How to enable WCF message logging
    • How to enable WCF tracing
    • How to use Health Monitoring in WCF
    • How to view log information
    • How to view trace information
    • How to log traces to a WMI provider
    • How to turn off audit failure suppression


    • How to authenticate users against the SQL Membership Provider
    • How to authenticate users against Active Directory
    • How to authenticate users against Active Directory without windows authentication
    • How to authenticate users with certificates
    • How to map certificates with windows accounts
    • How to authenticate users against a custom user store
    • How to authenticate users with Kerberos direct to support non-WCF clients with windows authentication


    • How to authorize imperatively
    • How to authorize declaratively
    • How to authorize users against Windows groups
    • How to authorize users against Windows groups using the AspNetWindowsTokenRoleProvider
    • How to authorize users against the SQL Role Provider
    • How to authorize users against the ASP.Net Role Provider
    • How to assign the current principal with IAuthorizationPolicy to allow authorization using custom authentication

    Configuration Management

    • How to encrypt sensitive data in your configuration files
    • How to run your service under a specific identity
    • How to create a service account for your WCF service
    • How to stop clients from referencing your service
    • How to protect against message replay attacks

    Deployment Considerations

    • How to configure certificates to enable SSL in IIS
    • How to map Windows accounts with certificates
    • How to create a Service Principle Name (SPN)
    • How to configure WCF for NATs and Firewalls
    • How to create an X.509 certificate

    Exception Management

    • How to shield exception information with fault contracts
    • How to create an error handler to log details of faults for auditing purposes
    • How to handle unhandled exceptions in downstream services
    • How to throw an exception with complex types or data contracts with a fault exception
    • How to handle unknown faults in a service
    • How to implement a data contract to propagate exception details for debugging purposes
    • How to implement fault contracts in call back functions


    • How to host WCF in IIS
    • How to host WCF in a Windows service
    • How to self-host WCF
    • How to configure a least-privilege account to host your service


    • How to choose between trusted subsystem and impersonation/delegation
    • How to impersonate the original caller when using Windows authentication
    • How to impersonate programmatically in WCF
    • How to impersonate declaratively in WCF
    • How to delegate the original caller to call backend services when using Windows authentication
    • How to impersonate the original caller without Windows authentication
    • How to impersonate the original caller using S4U Kerberos extensions.
    • How to delegate the original caller using S4U Kerberos extensions.
    • How to impersonate and delegate using LogonUser Windows API
    • How to flow the original caller from an ASP.NET client to WCF
    • How to control access to a remote resource based on the original callers identity.

    Input Validation

    • How to protect your service from malicious messages
    • How to protect your service from malicious input
    • How to protect your service from denial of service attacks
    • How to validate parameters with parameter inspectors
    • How to validate parameters with message inspectors using schemas
    • How to validate data contracts with message inspectors using schemas
    • How to validate message contracts with message inspectors using schemas
    • How to use regular expressions validate format, range and length in schemas
    • How to validate inbound messages on a service
    • How to validate outbound messages on a service
    • How to validate outbound messages on the client
    • How to validate inbound messages on the client
    • How to validate input parameters
    • How to validate output parameters

    Message Security

    • How to use message security
    • How to partially encrypt a message
    • How to use out-of-band credentials with message security

    Proxy Considerations

    • How to avoid proxy spoofing
    • How to expose service metadata for your clients
    • How to create a proxy to a service hosted in IIS that requires certificate authentication and transport security

    Sensitive Data

    • How to encrypt sensitive data in configuration files
    • How to protect sensitive data in memory
    • How to protect sensitive data on the network

    Transport Security

    • How to use transport security
    • How to use secure conversations in WCF

    X.509 Certificates

    • How to create a temporary X.509 certificate for transport security
    • How to create a temporary X.509 certificate for message security
    • How to create a temporary X.509 certificate for certificate authentication

    My Related Posts

  • J.D. Meier's Blog

    Ken Blanchard Speaks at Microsoft


    Ken Blanchard spoke at Microsoft last week.  He's all about empowering people, growing people, and helping everybody get an A.  This post is my notes from the session.


    Catch People Doing Something Right, Accentuate the Positive
    I'm putting this right up front because Ken said if there was only one thing he could be remembered for, he would want it to be:

    "Catch People Doing Something Right, Accentuate the Positive."

    Random Highlights
    Here's a sampling of some of the one-liners and insights from the session:

    • The triad is the provider of choice, employer of choice, investment of choice.
    • People will compete with you in garages -- have the triad.
    • Bring your brains to the job vs. kiss up the hierarchy.
    • Write the final exam up front.
    • Life's about getting A's.  Everybody gets A's.
    • The journey of an effective leader starts with self-leadership (who are you)
    • None of us is as smart as all of us (the collective brain)
    • Don't ask yes/no questions -- ask, what's one thing we could have done differently to make your experience better?
    • Know your rank order values.  Walk your values.  Don't have too many values.
    • Profit is the applause you get for taking care of customers and being a motivating place to work.
    • Get customers telling stories about you.
    • Who does she work for? a duck or an eagle? Ducks quack excuses.  Eagles soar above the crowd.   Bring your brains to work.
    • You got what you got (your team), what are you going to do?
    • Help people accomplish goals and have goals tied into the organization.
    • Now you have the position, don't use it (don't use your position -- it's on loan.)
    • All the important stickers went on people (people are the most important asset.)
    • Ken's favorite insight from the movie Ghost - "You can take the love with you."
    • What Ken's mom taught him -- "Don't act like you're better than anybody ...but don't let anybody act like they're better than you."

    Philanthropy is the News Around the World
    Ken travels the world and the big news he kept hearing about was the philanthropy.  Specifically, the news was focused on Bill Gates and Warren Buffet.  The fact that Buffet trusts the Bill & Melinda Gates Foundation to help the world sends a powerful message.

    4 Keys to Lead at a Higher Level
    Ken framed out 4 keys to lead at a higher level:

    1. Set your sights on the right target and vision.  Ken reminded us that since Alice didn't know where she wanted to go, the Chesire cat told her that the direction doesn't matter.
    2. Treat your customers right.  Decide, discover, and deliver.
    3. Treat your people right.  If you don't treat your people right, they won't take care of your customers (the customers are the only people they can beat up.)
    4. Have the right kind of leadership.  Effective leadership starts on the inside.  You don't own the position, it's on loan.  Be a servant leader over a self-serving leader.

    Decide, Discover and Deliver
    To treat your customers right, Ken provided a decide, discover, deliver approach:

    • Decide.  Decide what experience you want your customers to have.  For example, one gas station used the "Indianapolis pitstop experience" and had the slogan, "jump to the pump." 
    • Discover.  Listen to what your customers want and see if it makes sense to include their suggestions in your vision.  Don't ask yes/no questions -- ask, what's one thing we could have done differently to make your experience better?
    • Deliver.   To implement your customer service vision, invert the traditional pyramid and empower your people.

    Turn the Pyramid Upside Down
    Turn the pyramid upside down.  Have your team bring their brains to work vs. kiss up the hierarchy.  Don't have them be ducks (who just quack excuses why they can't do this or can't do that.) Empower them to be eagles who soar above the crowd. 

    A Fortunate 500 List According to Ken Blanchard
    Ken suggested the idea of a Fortunate 500 list.  A Fortunate 500 Company would have a triple bottom line and be a good citizen in the community.

    Customers, Business, Employees (The Triple Bottom Line)
    The triple bottom line includes:

    1. Provider of choice (customers)
    2. Employer of choice (employees)
    3. Investment of choice (business)

    Ken remarked that profit is the applause you get for taking care of customers and being a motivating place to work.

    Organizational Vitality, Employee Passion, Customer Devotion
    Ken outlined the keys to organizational vitality:

    • Organizational vitality.  Organizational vitality is supported by customer devotion and employee passion (which support each other).  The employees don't see strategic initiatives in their day to day, so the biggest impact on org vitality is how does their boss threat them and how are they evaluated? (fair/just?)
    • Strategic leadership.  Strategic leadership supports org vitality.  Strategic leadership includes vision, culture, and strategic imperatives.
    • Organizational leadership.  Organizational leadership supports employee passion and customer devotion.   Organizational leadership includes policies and procedures (indirect relationship on strategy), leader behaviors, and fairness / justice.

    From Self-Leadership to Organizational Leadership
    The journey of an effective leader starts with self-leadership (who are you) and progresses to organizational leadership:

    • Self-leadership (who are you)
    • One-to-one leadership
    • Team leadership
    • Organizational leadership

    Ken noted that one of his favorite mantras is -- none of us is as smart as all of us.

    3 Skills of Situational Leader
    Ken identified 3 skills of a situational leader:

    1. Diagnosis - figuring our the development level.
    2. Flexibility - adapting your leadership style based on the development level.
    3. Partnering for performance - helping everybody get A's. 

    The 4 D's (Development Level)
    The four development levels vary by competence and motivation.  If you can identify which development level somebody is in, you can use the right leadership style:

    • D1 - Enthusiastic beginner (low competence, high commitment)
    • D2 - Disillusioned learner (low competence, low commitment)
    • D3 - The capable, but cautious performer (low to some competence, variable commitment)
    • D4 - The self-reliant achiever (high competence, high commitment)

    4 Leadership Styles
    The four leadership styles range from directing to delegating:

    • S1 - Directive
    • S2 - Coaching
    • S3 - Supportive
    • S4 - Delegating

    Your leadership style varies by how you need to teach skills and provide motivation.   You match your leadership style based on the development level.

    More Supporting, Less Delegating
    Ken noted that the most common style in tech is delegating (telling folks what to do), but that it only works if you have self-reliant achievers.  He said lots of situations where somebody fails, it's because the leader didn't spend enough time supporting.  For example, somebody might be great at sales, but poor at administration and could use more support.

    Don't Be a Seagul
    Ken described the seagul type manager:

    1. Flies in
    2. Makes a lot of noise
    3. Dumps on everyone
    4. Flies out

    Yuck!  Don't be a seagul.

    How to Manage Effectively
    Ken gave us a recipe for managing effectively:

    1. Teach situational leadership II
    2. Agree on goals
    3. Agree on level of performance
    4. Diagnose development level
    5. Agree on appropriate leadership style
    6. Follow up on agreements

    Leadership vs. Management
    When a colleague asked Ken about his thoughts on the difference between leadership and management, he said he doesn't get involved in the debate.  He doesn't think management should play 2nd fiddle.

    Don't Rank Employees on a Bell Curve
    Ken made a few key points against ranking employees on a bell curve:

    • Why screw a certain percentage?
    • You don't hire losers to fill slots.
    • Putting your new people at the bottom doesn't encourage them.

    Help Everybody Get A's
    Ken's recipe for results is:

    • Give out the final exam up front
    • Teach people answers to get the A's
    • Demonstrate how you've helped them get A's each quarter
    • Have an informal formal review each quarter
    • A review at the end of the year should be a review -- not a surprise.

    Share Them With Your Competition
    What happens if you give help people get A's but they don't get A's:

    • If they're a good citizen, then help them find the right position.
    • If they're not a good citizen, then share them with your competition.

    From self-serving leaders to Servant Leadership
    Ken gave us three ways that somebody moves from a self-serving leader to servant-leadership:

    1. Near death experience
    2. Spiritual awakening
    3. Be a role model

    Basically it's life-changing events or by following an example.

    Egos Anonymous
    There's two ends of the spectrum with ego issues:

    1. False pride
    2. Self-doubt / fear

    The problem with ego issues is that the world spins around you.  Ken said the key is to put the focus somewhere else.  When you put the focus on something else, the fear goes away.

    Ken told us about "Egos Anonymous" meetings.   He said at the meetings, people introduce themselves with "I'm an ego maniac, the last time my ego got in the way ..." 

    The irony is, everybody wants to go last to be more clever, funnier -- and that's an ego thing.

    Bigger Emphasis on Results or Developing People?
    Ken pointed out that it's not an either/or it's a both/and.  The keys are:

    1. Fixing motivation.
    2. Fixing capability.

    The Secret of Great Leaders
    Ken told us the secret of great leaders:

    • Values, results and people
    • Emphasis on results
    • Significant investment in their lives
    • Express appreciation

    You're Learning or Dying
    Ken told us we're learning or dying:

    • Reinvent continuously.
    • How will your resume be different next year?
    • Are you learning from mentors?

    SERVE - What Great Leaders Know and Do
    Ken explained that SERVE is what great leaders know and do:

    • See the future.
    • Engage and develop others
    • Reinvent continuously.
    • Value results and relationship.
    • Embody the values.

    Leadership is Love
    Ken told us leadership is love:

    • Loving your mission
    • Loving your customers
    • Loving your people
    • Loving yourself -- enough to get out of the way so others can be magnificent.

    How To Implement the program
    Ken said he's seen remarkable impact when organizations apply the knowledge.  He said there's three keys:

    1. Performance management program (3,4,5x the difference)
    2. Situational leadership
    3. Final exam.

    Wrap Up
    At the end of the talk, I met Ken and he signed my copy of The 3 Keys to Empowerment.   What surprised me the most was how down to earth and engaged in the moment he was.   I thanked him for teaching people situational leadership.  I asked him where the II part came from in Situational Leadership II and he told me the story of the split.   I told him it would be great to be able to read stories like that in his blog, if he had one. 

    3 Actions
    As a habit, I challenge myself to turn what I learn into three things I can apply.  There's always more I can do, but I start with three.  Here they are:

    1. Help everybody get A's.  I'll start by diagnose the development levels on my team.  Does somebody on the team need more encouragement or more instruction than they're getting right now?
    2. Figure out how my resume will be different next year.  I used to do this exercise regularly, but it's been a while.  Flashing forward is a great way to help me choose certain paths over others.
    3. Decide, discover, and deliver the right customer experience.  Very practically put, stop asking yes, no questions and start asking, what's one thing we could have done differently to make your experience better?
  • J.D. Meier's Blog

    Decision Making with Criteria and Weight


    If you need to make an important decision, the following can help:

    1. Identify the criteria
    2. Identify the weighting of each criteria
    3. Rate your options against the criteria and multiply by the weightings

    For example, when I was giving input on hiring our PUM, I identified the following criteria:

    • Microsoft Experience
    • patterns & practices Experience
    • Attract the right talent
    • Execution
    • Customer-connection
    • Engineering Competence
    • Business Competence
    • Political Competence

    I then assigned a weighting.  For example:

    • Microsoft Experience - (2)
    • patterns & practices Experience - (3)
    • Attract the right talent - (3)
    • Execution - (3)
    • Customer-connection - (3)
    • Engineering Competence  - (2)
    • Business Competence - (2)
    • Political Competence - (2)

    I rated the candidate against each criteria and then multiplied by the weighting.  This gave me a quick frame to compare different candidates as well as have more meaningful dialogues with others.  The actual numbers were less important than testing and clarifying criteria.

  • J.D. Meier's Blog

    6 New patterns & practices WCF Security How Tos


    We have 6 new How Tos for this week's release of our patterns & practices WCF Security Guidance Project.

    WCF Security How Tos

    My Related Posts

  • J.D. Meier's Blog

    Monthly Improvement Sprints


    Each month I pick a focus or a theme for my improvement sprint.  I find it's easier to start and stop a new sprint each month, rather than start in the middle of a month and try and remember when to stop.  I also like the fact that each month is a fresh start.  Cycling through a new improvement sprint each month, gives me 12 sprints I can allocate to whatever I want or need to focus on.  This keeps me learning and growing throughout the year in a simple, but systematic way.  Each month I can do another sprint on the same topic or pick a new area to explore.  Periodically, I try to inject an improvement sprint that focuses on something physical.  For example, last year I did a living foods improvement sprint and in another sprint I worked up to roller-blading 15+ miles a day.

    Here's the improvement sprints I've done so far this year:

    • JAN - Leadership skills / Microsoft leadership skills
    • FEB - Effective blogging
    • MAR - Effective blogging (I continued researching effective blogging practices)
    • APR - SEO practices (studying blogging practices lead me down the SEO path)

    Sometimes I'll do more than one sprint for a month, but in general I try to stick with one theme.  The power of the sprint is the focus.  Its easier for me to stay focused when I remind myself I can switch focus each month.

    My Related Posts

  • J.D. Meier's Blog

    patterns & practices WCF Security Questions and Answers Now Available


    What are your key security-related questions with WCF?  More importantly, what are the answers?  For this week's release of our WCF Security Guidance Project, we posted our WCF Security Q&A (Questions and Answers) to CodePlex. 

    To create the questions and answers set, we first gathered and organized recurring questions from our field, support, customers and forums.  We then worked through to create precise answers.  What you get is a browsable collection of questions and answers, organized by our security frame.   The security frame maps to actionable categories of your application.

    Here's a snapshot of the questions from our Q&A, but you can see our answers explained at our WCF Security Guidance project site.

    Design Considerations

    • How do I decide on an authentication strategy?
    • How do I decide on an authorization strategy?
    • When should I use message security vs. transport security?
    • How do I use my existing Active Directory infrastructure?
    • What bindings should I use over the Internet?
    • What bindings should I use over the Intranet?
    • When should I use resource-based authorization vs. roles-based authorization?
    • When should I impersonate the original caller?
    • When should I flow the original caller’s identity to back-end resources?
    • How do I migrate to WCF from an ASMX web service?
    • How do I migrate to WCF from a COM application?
    • How do I migrate to WCF from a DCOM application?
    • How do I migrate to WCF from a WSE application?

    Auditing and Logging

    • What WCF Service security events should be logged?
    • How do I enable logging and auditing in WCF?
    • How do I enable auditing in WCF?
    • How do I stop my service if there has been an auditing failure?
    • How do I log important business events in WCF?
    • How do I implement log throttling in WCF?
    • How do I use Health Monitoring Feature with WCF?
    • How do I protect my log files?
    • How to I pass user identity information in a message for auditing purpose?


    • How do I decide on an authentication strategy in WCF?
    • When should I use brokered authentication?
    • When should I use the SQL Server Membership provider?
    • How do I authenticate against Active Directory?
    • How do I authenticate against a SQL store?
    • How do I authenticate against a custom store?
    • How do I protect passwords in my user store?
    • How do I use certificate authentication with X.509 certificates?
    • What is the most common authentication scenario for intranet applications?
    • What is the most common authentication scenario for internet applications?
    • How do I support authentication for multiple client types?
    • What is federated security?
    • How do I send credentials in the message when I am using transport security?
    • How do I avoid cleartext passwords?


    • How do I decide on an authorization strategy in WCF?
    • What’s the difference between resource-based, roles-based and claims-based authorization?
    • How do I use Windows groups for role authorization in WCF?
    • How do I use the SQL Role provider for ASPNET role authorization in WCF?
    • How do I use the Windows Token role provider for ASPNET role authorization in WCF?
    • How do I use the Authorization Store role provider for ASPNET role authorization in WCF?
    • What’s the difference between declarative and imperative roles authorization?
    • How do I restrict access to WCF operations to specific Windows users?
    • How do I associate roles with a certificate?
    • What is a service principle name (SPN)?
    • How do I create a service principle name (SPN)?


    • What is a binding?
    • What bindings are available?
    • Which bindings are best suited for the Internet?
    • Which bindings are best suited for the Intranet?
    • How do I choose an appropriate binding?
    • Configuration Management
    • How do I encrypt sensitive data in WCF configuration file?
    • How do I run a WCF Service with a particular identity?
    • How do I create a service account for running my WCF Service?
    • When should I use a configuration file versus the WCF object model?
    • What is a metadata exchange (MEX) binding?
    • How do I keep clients from referencing my service?

    Exception Management

    • How do I implement a global exception handler?
    • What is a fault contract?
    • How do I define a fault contract?
    • How do I avoid sending exception details to the client?


    • How do I configure a least privileged account to host my service?
    • When should I host my service in IIS?
    • When should I host my service in a Windows service?
    • When should I self-host my service?
    • Impersonation/Delegation
    • What are my impersonation options?
    • What is the difference between impersonation and delegation?
    • How do I impersonate the original caller for an operation call?
    • How do I temporarily impersonate the original caller in an operation call?
    • How do I impersonate a specific (fixed) identity?
    • What is constrained delegation?
    • What is protocol transition?
    • How do I flow original caller from ASP.NET client to WCF Service?
    • What is the difference between declarative and programmatic impersonation?
    • What is the trusted subsystem model?
    • When should I flow the original caller to back-end code?
    • How do I control access to a remote resource based on the original caller’s identity?

    Input/Data Validation

    • How do I implement input and data validation in WCF?
    • What is schema validation?
    • What is parameter validation?
    • Should I validate before or after message serialization?
    • How do I protect my service from denial of service attacks?
    • How do I protect my service from malicious input attacks?
    • How do I protect my service from malformed messages?
    • Message Protection
    • When should I use message security?
    • When should I use transport security?
    • How do I protect my message when there are intermediaries routing my message?
    • How do I protect my message when there are multiple protocols used during message
    • transit?
    • How do I implement partial message encryption?

    Proxy Considerations

    • When should I use a channel factory?
    • When do I need to expose a metadata exchange endpoint for my service?
    • How do I avoid proxy spoofing?

    Sensitive Data

    • How do I protect sensitive data in configuration files?
    • How do I protect sensitive data in memory?
    • How do I protect my metadata?
    • How do I protect sensitive data from being read on the wire?
    • How do I protect sensitive data from being tampered with on the wire?
    • How do I authenticate a message was sent by the expected sender?
    • How do I encrypt data within my message?

    X.509 Certificates

    • How do I create X.509 certificates?
    • Do I need to create a certificate signed by the root CA certificate?
    • How do I use X.509 certificate revocation?
    • How do I authenticate users with X.509 certificates, and then perform role-based access control using an Active Directory domain?

    Deployment Considerations

    • What are the additional considerations for using WCF in a webfarm?
    • How do I configure WCF for NATs and Firewalls?
    • How do I configure Active Directory groups and accounts for role-based authorization checks?
    • How do I create an X.509 certificate?
    • When should I use a Service Principle Name (SPN)?
    • How do I configure a least privileged account for my service?

    My Related Posts

  • J.D. Meier's Blog

    patterns & practices WCF 3.5 Security Guidelines Now Available


    For this week's release in our patterns & practices WCF Security Guidance project, we released our first version of our WCF 3.5 Security Guidelines.  Each guideline is a nugget of what to do, why, and how.  The goal of the guideline format is to take a lot of information, compress it down, and turn insight into action.

    The downside is that it's tough to create prescriptive guidelines that are generic enough to be reusable, but specific enough to be helpful.  The upside is that customers find the guidelines help them cut through a lot of information and take action.  We contextualize the guidelines as much as we can, but ultimately you're in the best position to do the pattern matching to find which guidelines are relevant for your scenarios, and how you need to tailor them.

    Here's a snapshot of the guidelines, but you can see our security guidelines explained at our WCF Security Guidance project site.

    Our WCF Security guidelines are organized using the following buckets:

    • Auditing and Logging
    • Authentication
    • Authorization
    • Binding
    • Configuration Management
    • Exception Management
    • Hosting
    • Impersonation and Delegation
    • Input/Data Validation
    • Proxy Considerations
    • Deployment considerations 

    Auditing and Logging

    • Use WCF auditing to audit your service
    • If non-repudiation is important, consider setting SuppressAuditFailure property to false
    • Use message logging to log operations on your service
    • Instrument for user management events
    • Instrument for significant business operations
    • Protect log files from unauthorized access
    • Do not log sensitive information


    • Know your authentication options
    • Use Windows Authentication when you can
    • If you support non-WCF clients using windows authentication and message security, consider using the Kerberos direct option
    • If your users are in AD, but you can’t use windows authentication, consider using username authentication
    • If your clients have certificates, consider using client certificate authentication
    • If you need to streamline certificate distribution to your clients for message encryption, consider using the negotiate credentials option
    • If your users are in a custom store, consider using username authentication with a custom validator
    • If your users are in a SQL membership store, use the SQL Membership Provider
    • If your partner applications need to be authenticated when calling WCF services, use client certificate authentication.
    • If you are using username authentication, use SQL Server Membership Provider instead of custom authentication
    • If you need to support intermediaries and a variety of transports between client and service, use message security to protect credentials
    • If you are using username authentication, validate user login information
    • Do not store passwords directly in the user store
    • Enforce strong passwords
    • Protect access to your credential store
    • If you are using Windows Forms to connect to WCF, do not cache credentials


    • If you use ASP.NET roles, use the ASP.NET Role Provider
    • If you use windows groups for authorization, use ASP.NET Role Provider with AspNetWindowsTokenRoleProvider
    • If you store role information in SQL, consider using the SQL Server Role Provider for roles authorization
    • If you store role information in Windows Groups, consider using the WCF PrincipalPermissionAttribute class for roles authorization
    • If you need to authorize access to WCF operations, use declarative authorization
    • If you need to perform fine-grained authorization based on business logic, use imperative authorization


    • If you need to support clients over the internet, consider using wsHttpBinding.
    • If you need to expose your WCF service to legacy clients as an ASMX web service, use basicHttpBinding
    • If you need to support remote WCF clients within an intranet, consider using netTcpBinding.
    • If you need to support local WCF clients, consider using netNamedPipeBinding.
    • If you need to support disconnected queued calls, use netMsmqBinding.
    • If you need to support bidirectional communication between WCF Client and WCF service, use wsDualHttpBinding.

    Configuration Management

    • Use Replay detection to protect against message replay attacks
    • If you host your service in a Windows service, expose a metadata exchange (mex) binding
    • If you don’t want to expose your WSDL, turn off HttpGetEnabled and metadata exchange (mex)
    • Manage bindings and endpoints in config not code
    • Associate names with the service configuration when you create service behavior, endpoint behavior, and binding configuration
    • Encrypt configuration sections that contain sensitive data

    Exception Management

    • Use structured exception handling
    • Do not divulge exception details to clients in production
    • Use a fault contract to return error information to clients
    • Use a global exception handler to catch unhandled exceptions


    • If you are hosting your service in a Windows Service, use a least privileged custom domain account
    • If you are hosting your service in IIS, use a least privileged service account
    • Use IIS to host your service unless you need to use a transport that IIS does not support

    Impersonation and Delegation

    • Know the impersonation options
    • If you have to flow the original caller, use constrained delegation
    • Consider LogonUser when you need to impersonate but you don’t have trusted delegation
    • Consider S4U when you need a Windows token and you don’t have the original caller’s credentials
    • Use programmatic impersonation to impersonate based on business logic
    • When impersonating programmatically be sure to revert to original context
    • Only impersonate on operations that require it
    • Use OperationBehavior to impersonate declaratively

    Input/Data Validation

    • If you need to validate parameters, use parameter inspectors
    • If your service has operations that accept message or data contracts, use schemas to validate your messages
    • If you need to do schema validation, use message inspectors
    • Validate operation parameters for length, range, format and type
    • Validate parameter input on the server
    • Validate service responses on the client
    • Do not rely on client-side validation
    • Avoid user-supplied file name and path input
    • Do not echo untrusted input

    Proxy Considerations

    • Publish your metadata over HTTPS to protect your clients from proxy spoofing
    • If you turn off mutual authentication, be aware of service spoofing

    Deployment considerations

    • Do not use temporary certificates in production
    • If you are using a custom domain account in the identity pool for your WCF application, create an SPN for Kerberos to authenticate the client.
    • If you are using a custom service account and need to use trusted for delegation, create an SPN
    • If you are hosting your service in a Windows Service, using a custom domain identity, and ASP.NET needs to use constrained trusted for delegation when calling the service, create an SPN
    • Use IIS to host your service unless you need to use a transport that IIS does not support
    • Use a least privileged account to run your WCF service
    • Protect sensitive data in your configuration files

    My Related Posts

  • J.D. Meier's Blog

    patterns & practices WCF Security Guidance: Updated Application Scenarios


    For this week's release in our patterns & practices WCF Security Guidance project, we added new sections to our WCF Security Application Scenarios.  We added sections for analysis, code and configuration examples.  The analysis section explains the rationale behind some of the decisions. 

    The idea behind the application scenarios is to show you a before and after look of end-to-end solutions.  Rather than a single solution, we give you a set of solutions to pick from.  The main parameters that vary in each solution include: Intranet vs. Internet, ASP.NET client vs. Windows Forms clients, TCP vs. HTTP, impersonation/delegation vs. trusted subsystem, and AD (domain credentials) vs. a custom user store.

    WCF Security Application Scenarios


    Note that if there's enough interest and time, we'll add a scenario that shows accessing an existing custom user store (i.e. you aren't using Membership.) 

    My Related Posts

  • J.D. Meier's Blog

    Security Principles


    If you know the underlying principles for security, you can be more effective in your security design.  While working on Improving Web Application Security: Threats and Countermeasures, my team focused on creating a durable set of security principles.  The challenge was to make the principles more useful.  It's one thing to know the principles, but another to turn it into action. 

    Turning Insights Into Action

    To make the principles more useful, we organized them using our Security Frame.  Our Security Frame is a set of actionable, relevant categories that shape your key engineering and deployment decisions.  With the Security Frame we could quickly find principles related to authentication, or authorization or input validation ... etc. 

    Once we had these principles and this organizing frame, we could then evaluate technologies against it to find effective, principle-based techniques.  For example, when we analyzed doing input and data validation in ASP.NET, we focused on finding the best ways to constrain, reject, and sanitize input.  For constraining input, we focused on checking for length, range, format and type.  Using these strategies both shortened our learning curve and improved our results.

    Core Security Principles

    We started with a firm foundation of core security principles.  These influenced the rest of our security design principles.  Here's the core security principles we started with:

    • Adopt the principle of least privilege - Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised
    • Use defense in depth.   Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
    • Don't trust user input.  Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters.
    • Use secure defaults.   If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change
    • Don't rely on security by obscurity.   Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it's better to use platform features or proven techniques for securing your data.
    • Check at the gate.   Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.
    • Assume external systems are insecure.  If you don't own it, don't assume security is taken care of for you.
    • Reduce Surface Area   Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don't expose any more information than is required when returning an error message to the end user.
    • Fail to a secure mode.   your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don't include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
    • Security is a concern across all of your application layers and tiers.   Remember you are only as secure as your weakest link.
    • If you don't use it, disable it.   You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn't use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

    Frame for Organizing Security Design Principles

    Rather than a laundry list of security principles, you can use the Security Frame as a way to organize and share security principles:

    • Auditing and Logging
    • Authentication
    • Authorization
    • Configuration Management
    • Cryptography
    • Exception Management
    • Input / Data Validation
    • Sensitive Data
    • Session Management

    Auditing and Logging

    Here's our security design principles for auditing and logging:

    • Audit and log access across application tiers.   Audit and log access across the tiers of your application for non-repudiation. Use a combination of application-level logging and platform auditing features, such as Windows, IIS, and SQL Server auditing.
    • Consider identity flow.   You have two basic choices. You can flow the caller's identity at the operating system level or you can flow the caller's identity at the application level and use trusted identities to access back-end resources.
    • Log key events.   The types of events that should be logged include successful and failed logon attempts, modification of data, retrieval of data, network communications, and administrative functions such as the enabling or disabling of logging. Logs should include the time of the event, the location of the event including the machine name, the identity of the current user, the identity of the process initiating the event, and a detailed description of the event
    • Protect log files.   Protect log files using  access control lists and restrict access to the log files. This makes it more difficult for attackers to tamper with log files to cover their tracks. Minimize the number of individuals who can manipulate the log files. Authorize access only to highly trusted accounts such as administrators.
    • Back up and analyze log files regularly.   There's no point in logging activity if the log files are never analyzed. Log files should be removed from production servers on a regular basis. The frequency of removal is dependent upon your application's level of activity. Your design should consider the way that log files will be retrieved and moved to offline servers for analysis. Any additional protocols and ports opened on the Web server for this purpose must be securely locked down.


    Here's our security design principles for authentication:

    • Separate public and restricted areas.   A public area of your site can be accessed by any user anonymously. Restricted areas can be accessed only by specific individuals and the users must authenticate with the site.  By partitioning your site into public and restricted access areas, you can apply separate authentication and authorization rules across the site.
    • Use account lockout policies for end-user accounts.   Disable end-user accounts or write events to a log after a set number of failed logon attempts. With Forms authentication, these policies are the responsibility of the application and must be incorporated into the application design. Be careful that account lockout policies cannot be abused in denial of service attacks.
    • Support password expiration periods. Passwords should not be static and should be changed as part of routine password maintenance through password expiration periods. Consider providing this type of facility during application design.
    • Be able to disable accounts.  If the system is compromised, being able to deliberately invalidate credentials or disable accounts can prevent additional attacks.
    • Do not store passwords in user stores.  If you must verify passwords, it is not necessary to actually store the passwords. Instead, store a one way hash value and then re-compute the hash using the user-supplied passwords. To mitigate the threat of dictionary attacks against the user store, use strong passwords and incorporate a random salt value with the password.
    • Require strong passwords.   Do not make it easy for attackers to crack passwords. There are many guidelines available, but a general practice is to require a minimum of eight characters and a mixture of uppercase and lowercase characters, numbers, and special characters. Whether you are using the platform to enforce these for you, or you are developing your own validation, this step is necessary to counter brute-force attacks where an attacker tries to crack a password through systematic trial and error. Use regular expressions to help with strong password validation.
    • Do not send passwords over the wire in plaintext.   Plaintext passwords sent over a network are vulnerable to eavesdropping. To address this threat, secure the communication channel, for example, by using SSL to encrypt the traffic.
    • Protect authentication cookies.   A stolen authentication cookie is a stolen logon. Protect authentication tickets using encryption and secure communication channels. Also limit the time interval in which an authentication ticket remains valid, to counter the spoofing threat that can result from replay attacks, where an attacker captures the cookie and uses it to gain illicit access to your site. Reducing the cookie timeout does not prevent replay attacks but it does limit the amount of time the attacker has to access the site using the stolen cookie.


    Here's our security design principles for authorization:

    • Use multiple gatekeepers.   By combining multiple gatekeepers across layers and tiers, you can develop an effective authorization strategy.
    • Restrict user access to system-level resources.   System level resources include files, folders, registry keys, Active Directory objects, database objects, event logs, and so on. Use access control lists to restrict which users can access what resources and the types of operations that they can perform. Pay particular attention to anonymous Internet user accounts; lock these down on resources that explicitly deny access to anonymous users.
    • Consider authorization granularity.   There are three common authorization models, each with varying degrees of granularity and scalability: (1.) the impersonation model providing per end user authorization granularity, (2.) the trusted subsystem model uses the application's process identity for resource access, and (3.) the hybrid model uses multiple trusted service identities for downstream resource access. The most granular approach relies on impersonation. The impersonation model provides per end user authorization granularity.

    Configuration Management

    Here's our security design principles for configuration management:

    • Protect your administration interfaces.   It is important that configuration management functionality is accessible only by authorized operators and administrators. A key part is to enforce strong authentication over your administration interfaces, for example, by using certificates. If possible, limit or avoid the use of remote administration and require administrators to log on locally. If you need to support remote administration, use encrypted channels, for example, with SSL or VPN technology, because of the sensitive nature of the data passed over administrative interfaces.
    • Protect your configuration store. Text-based configuration files, the registry, and databases are common options for storing application configuration data. If possible, avoid using configuration files in the application's Web space to prevent possible server configuration vulnerabilities resulting in the download of configuration files. Whatever approach you use, secure access to the configuration store, for example, by using access control lists or database permissions. Also avoid storing plaintext secrets such as database connection strings or account credentials. Secure these items using encryption and then restrict access to the registry key, file, or table that contains the encrypted data.
    • Maintain separate administration privileges.   If the functionality supported by the features of your application's configuration management varies based on the role of the administrator, consider authorizing each role separately by using role-based authorization. For example, the person responsible for updating a site's static content should not necessarily be allowed to change a customer's credit limit.
    • Use least privileged process and service accounts.  An important aspect of your application's configuration is the process accounts used to run the Web server process and the service accounts used to access downstream resources and systems. Make sure these accounts are set up as least privileged. If an attacker manages to take control of a process, the process identity should have very restricted access to the file system and other system resources to limit the damage that can be done.


    Here's our security design principles for cryptography:

    • Do not develop your own cryptography.   Cryptographic algorithms and routines are notoriously difficult to develop successfully. As a result, you should use the tried and tested cryptographic services provided by the platform.
    • Keep unencrypted data close to the algorithm.   When passing plaintext to an algorithm, do not obtain the data until you are ready to use it, and store it in as few variables as possible.
    • Use the correct algorithm and correct key size.   It is important to make sure you choose the right algorithm for the right job and to make sure you use a key size that provides a sufficient degree of security. Larger key sizes generally increase security. The following list summarizes the major algorithms together with the key sizes that each uses: Data Encryption Standard (DES) 64-bit key (8 bytes) , TripleDES 128-bit key or 192-bit key (16 or 24 bytes) , Rijndael 128–256 bit keys (16–32 bytes) , RSA 384–16,384 bit keys (48–2,048 bytes) .  For large data encryption, use the TripleDES symmetric encryption algorithm. For slower and stronger encryption of large data, use Rijndael. To encrypt data that is to be stored for short periods of time, you can consider using a faster but weaker algorithm such as DES. For digital signatures, use Rivest, Shamir, and Adleman (RSA) or Digital Signature Algorithm (DSA). For hashing, use the Secure Hash Algorithm (SHA)1.0. For keyed hashes, use the Hash-based Message Authentication Code (HMAC) SHA1.0.
    • Protect your encryption keys.   An encryption key is a secret number used as input to the encryption and decryption processes. For encrypted data to remain secure, the key must be protected. If an attacker compromises the decryption key, your encrypted data is no longer secure.  Avoid key management when you can, and when you do need to store encryption keys, cycle your keys periodically.

    Exception Management

    Here's our security design principles for exception management:

    • Do not leak information to the client.   In the event of a failure, do not expose information that could lead to information disclosure. For example, do not expose stack trace details that include function names and line numbers in the case of debug builds (which should not be used on production servers). Instead, return generic error messages to the client.
    • Log detailed error messages.   Send detailed error messages to the error log. Send minimal information to the consumer of your service or application, such as a generic error message and custom error log ID that can subsequently be mapped to detailed message in the event logs. Make sure that you do not log passwords or other sensitive data.
    • Catch exceptions.  Use structured exception handling and catch exception conditions. Doing so avoids leaving your application in an inconsistent state that may lead to information disclosure. It also helps protect your application from denial of service attacks. Decide how to propagate exceptions internally in your application and give special consideration to what occurs at the application boundary.

    Input / Data Validation

    Here's our security design principles for input and data validation:

    • Assume all input is malicious.  Input validation starts with a fundamental supposition that all input is malicious until proven otherwise. Whether input comes from a service, a file share, a user, or a database, validate your input if the source is outside your trust boundary.
    • Centralize your approach.  Make your input validation strategy a core element of your application design. Consider a centralized approach to validation, for example, by using common validation and filtering code in shared libraries. This ensures that validation rules are applied consistently. It also reduces development effort and helps with future maintenance.  In many cases, individual fields require specific validation, for example, with specifically developed regular expressions. However, you can frequently factor out common routines to validate regularly used fields such as e-mail addresses, titles, names, postal addresses including ZIP or postal codes, and so on.
    • Do not rely on client-side validation.   Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript? Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security. This is an example of defense in depth.
    • Be careful with canonicalization issues.   Data in canonical form is in its most standard or simplest form. Canonicalization is the process of converting data to its canonical form. File paths and URLs are particularly prone to canonicalization issues and many well-known exploits are a direct result of canonicalization bugs.  You should generally try to avoid designing applications that accept input file names from the user to avoid canonicalization issues.
    • Constrain, reject, and sanitize your input.   The preferred approach to validating input is to constrain what you allow from the beginning. It is much easier to validate data for known valid types, patterns, and ranges than it is to validate data by looking for known bad characters. When you design your application, you know what your application expects. The range of valid data is generally a more finite set than potentially malicious input. However, for defense in depth you may also want to reject known bad input and then sanitize the input.
    • Encrypt sensitive cookie state.  Cookies may contain sensitive data such as session identifiers or data that is used as part of the server-side authorization process. To protect this type of data from unauthorized manipulation, use cryptography to encrypt the contents of the cookie.
    • Make sure that users do not bypass your checks.   Make sure that users do not bypass your checks by manipulating parameters. URL parameters can be manipulated by end users through the browser address text box. For example, the URL http://www.<YourSite>/<YourApp>/sessionId=10 has a value of 10 that can be changed to some random number to receive different output. Make sure that you check this in server-side code, not in client-side JavaScript, which can be disabled in the browser.
    • Validate all values sent from the client.   Restrict the fields that the user can enter and modify and validate all values coming from the client. If you have predefined values in your form fields, users can change them and post them back to receive different results. Permit only known good values wherever possible. For example, if the input field is for a state, only inputs matching a state postal code should be permitted.
    • Do not trust HTTP header information.   HTTP headers are sent at the start of HTTP requests and HTTP responses. Your Web application should make sure it does not base any security decision on information in the HTTP headers because it is easy for an attacker to manipulate the header. For example, the referrer field in the header contains the URL of the Web page from where the request originated. Do not make any security decisions based on the value of the referrer field, for example, to check whether the request originated from a page generated by the Web application, because the field is easily falsified.

    Sensitive Data

    Here's our security design principles for sensitive data:

    • Do not store secrets if you can avoid it.   Storing secrets in software in a completely secure fashion is not possible. An administrator, who has physical access to the server, can access the data. For example, it is not necessary to store a secret when all you need to do is verify whether a user knows the secret. In this case, you can store a hash value that represents the secret and compute the hash using the user-supplied value to verify whether the user knows the secret.
    • Do not store secrets in code.  Do not hard code secrets in code. Even if the source code is not exposed on the Web server, it is possible to extract string constants from compiled executable files. A configuration vulnerability may allow an attacker to retrieve the executable.
    • Do not store database connections, passwords, or keys in plaintext.   Avoid storing secrets such as database connection strings, passwords, and keys in plaintext. Use encryption and store encrypted strings.
    • Avoid storing secrets in the Local Security Authority (LSA).   Avoid the LSA because your application requires administration privileges to access it. This violates the core security principle of running with least privilege. Also, the LSA can store secrets in only a restricted number of slots. A better approach is to use DPAPI.
    • Use Data Protection API (DPAPI) for encrypting secrets.   To store secrets such as database connection strings or service account credentials, use DPAPI. The main advantage to using DPAPI is that the platform system manages the encryption/decryption key and it is not an issue for the application. The key is either tied to a Windows user account or to a specific computer, depending on flags passed to the DPAPI functions.   DPAPI is best suited for encrypting information that can be manually recreated when the master keys are lost, for example, because a damaged server requires an operating system re-install. Data that cannot be recovered because you do not know the plaintext value, for example, customer credit card details, require an alternate approach that uses traditional symmetric key-based cryptography such as the use of triple-DES.
    • Retrieve sensitive data on demand.   The preferred approach is to retrieve sensitive data on demand when it is needed instead of persisting or caching it in memory. For example, retrieve the encrypted secret when it is needed, decrypt it, use it, and then clear the memory (variable) used to hold the plaintext secret. If performance becomes an issue, consider caching along with potential security implications.
    • Encrypt the data or secure the communication channel.   If you are sending sensitive data over the network to the client, encrypt the data or secure the channel. A common practice is to use SSL between the client and Web server. Between servers, an increasingly common approach is to use IPSec. For securing sensitive data that flows through several intermediaries, for example, Web service Simple Object Access Protocol (SOAP) messages, use message level encryption.
    • Do not store sensitive data in persistent cookies.  Avoid storing sensitive data in persistent cookies. If you store plaintext data, the end user is able to see and modify the data. If you encrypt the data, key management can be a problem. For example, if the key used to encrypt the data in the cookie has expired and been recycled, the new key cannot decrypt the persistent cookie passed by the browser from the client.
    • Do not pass sensitive data using the HTTP-GET protocol.   You should avoid storing sensitive data using the HTTP-GET protocol because the protocol uses query strings to pass data. Sensitive data cannot be secured using query strings and query strings are often logged by the server

    Session Management

    Here's our security design principles for session management:

    • Use SSL to protect session authentication cookies.   Do not pass authentication cookies over HTTP connections. Set the secure cookie property within authentication cookies, which instructs browsers to send cookies back to the server only over HTTPS connections.
    • Encrypt the contents of the authentication cookies.   Encrypt the cookie contents even if you are using SSL. This prevents an attacker viewing or modifying the cookie if he manages to steal it through an XSS attack. In this event, the attacker could still use the cookie to access your application, but only while the cookie remains valid.
    • Limit session lifetime.   Reduce the lifetime of sessions to mitigate the risk of session hijacking and replay attacks. The shorter the session, the less time an attacker has to capture a session cookie and use it to access your application.
    • Protect session state from unauthorized access.   Consider how session state is to be stored. For optimum performance, you can store session state in the Web application's process address space. However, this approach has limited scalability and implications in Web farm scenarios, where requests from the same user cannot be guaranteed to be handled by the same server. You should secure the network link from the Web application to state store using IPSec or SSL to mitigate the risk of eavesdropping. Also consider how the Web application is to be authenticated by the state store. Use Windows authentication where possible to avoid passing plaintext authentication credentials across the network and to benefit from secure Windows account policies.

    Using the Security Design Principles

    This is simply a baseline set of principles so that you don't have to start from scratch.  You can build on this set and tailor for your specific context.  I find that while having a set of principles helps, that you can't stop there.  To share the knowledge and help others use the information, it's important to encapsulate the principles in patterns as well as show concrete examples and create precise, actionable guidelines for developers.  Personally, I've found Wikis to be the most effective way to share and manage the information.

    Additional Resources

    My Related Posts

  • J.D. Meier's Blog

    Stephen Covey Speaks at Microsoft


    Dr. Stephen Covey presented at Microsoft today.  It’s one thing to know the information; it’s another to experience the delivery live. 


    This post is a bit longer than usual, but hey, it’s not every day that Covey is in the house.  Here are some of my highlights from today’s session.

    The Lighthouse Story
    Covey opened with a story of Captain Horatio Hornblower.  As the story goes, one night at sea, Horatio awakens to find that a ship is in his sea-lane about 20 miles away and refuses to move.  Horatio commands the other ship to move starboard, 20 degrees at once.  The other ship refuses and tells Horatio that he should move his ship starboard, 20 degrees at once.  Next, Horatio tries to pull rank and size on the other ship, stating that he’s a captain and that he’s on a large battle ship.  The other ship replies, and it turns out it’s not actually a ship, but a lighthouse.

    The take away from the story is, there are lighthouse principles.  You don’t break them.  You only break yourself against them.  Don’t break yourself against lighthouse principles.

    Values and Principles
    Covey distinguished values from principles:

    • Values drive behavior.
    • Principles drive the consequences of behavior.

    The key take aways are:

    • If you take the short cuts in life, you pay the price of confidence and trust.
    • Build your personal value system on principles.

    Personal Mission Statement
    Covey asked us whether we had personal mission statements?  Some folks raised their hands.  He then asked us how many have them written down.  A lot less kept their hands raised.  I kept my hand raised because I happen to have my personal mission statement written down.  My personal mission statement is, “To find the best way for any person to succeed in any situation.”    I tie this back at work, where I try to help customers be as effective as possible, building on the Microsoft platform.

    Family Mission Statement
    Covey then challenged the audience whether we had mission statements for our families?  That one made me think.  He then challenged, if you asked your loved ones, would they know it?  Now there’s a good test! 

    He challenged us to go home and ask, “What’s the purpose of our family?”  He warned us though, that our families will know that we’ve been seminar’ed!

    Write and Visualize to Imprint on Your Subconscious
    Covey reminded us that writing down your mission imprints it in the subconscious mind.  He added that visualizing also imprints on the sub-concsious mind. 

    The take away is that you should write and visualize your mission statements.

    Keys to a Mission Statement
    Covey put it succinctly that a good mission statement is:

    • Memorizable.
    • Short.
    • Follows the natural laws of principles.

    Why a Mission Statement
    Covey told us that the power of a mission statement is that it governs every other decision.

    Sean Covey
    Covey introduced his son, Sean Covey.  Sean wrote The 7 Habits of Highly Effective Teenagers and The 6 Most Important Decisions You Will Ever Make.   When Covey introduced Sean, he also mentioned a 49th grand-child on the way.  49 … WOW!  That’s quite the impressive team.

    Point to True North
    Covey had us close our eyes and point to true North.  When we opened our eyes, it was obvious there was little consistency.  He said he gets similar results when he asks any department, group, or team – “what’s your purpose?”

    Urgent But Not Important
    Covey asked us how many struggle with work/life balance.  Many hands went up.  He then asked us what we think is the percentage of time we spend on things that are urgent, but not important. 

    He said people often report they feel they spend 50% of their time on urgent, but not important tasks.  Why is that?  Covey stated it’s because everybody defines purpose differently.

    Office Politics and Dysfunctional Activities
    Covey asked us how much time people spend in office politics.    By office politics, he meant, reading the tea leaves, dealing with hidden agendas, fighting cross-group conflict, … etc.  The data says that 75% of people claim they spend 25% of their time on these things.  25% say that 50% of their time is spent in dysfunctional activities.  Urgency replaces important activities.

    The key take away is that people feel they spend a lot of time on dysfunctional activities.

    Six Metastasizing Cancers (Victimism)
    Covey showed us a slide that listed what he called the Six Metastasizing Cancers:

    • Criticizing
    • Complaining
    • Comparing
    • Competing
    • Contending
    • Cynicism

    The take away here is that these are ineffective behaviors and you end up acting like a victim.

    Are You Utilized to Your Full Potential
    Covey asked us whether we can use our full talent and capacity in our organization.   He then asked us whether we feel the pressure to produce more for less.   The point here was to emphasize how there’s a demand for greater results, but that we’re not necessarily utilized to our full potential.

    It’s Not Behavior, It’s Not Attitude … It’s a Bad Map
    Covey gave us a scenario where somebody gets a map of Seattle.  The problem is, the map maker made a mistake.  It’s not really a map of Seattle.  It’s a map of Oregon.  With this map, you can’t even make it out of the airport.  There isn’t one corresponding point.

    Trying harder isn’t the answer.  If you double your speed, now you’re lost twice as fast.  Thinking negatively isn’t the problem.  Covey said some people might try to use a PMA (Positive Mental Attitude.)  Well, that doesn’t help either.  Now you’re all psyched up, but really you are just happy and contented in a lost state.

    The take away here is that it’s not behavior and it’s not attitude.  It’s a bad map.

    Covey told us that we need to be self-educating.  School taught us how to learn, but we need to continue to learn.  He said we need to be willing to pay the price to be self-educating, which includes being systematic and disciplined.

    Industrial Age vs. Knowledge Worker Age
    Covey points out that 20 years ago, it was about goods and services.  Today, it’s about knowledge workers.

    - Industrial Age Knowledge Worker Age
    Overall Philosophy Kind Control Unleash Talent
    Leadership Position (Formal Authority) Choice (Moral Authority)
    Culture Boss Centered Complementary Team, Servant Leadership
    People Expense Asset
    Motivation External Internal (Inspiration)
    Management The Boss owns responsibility for results, therefore manages and motivates. The culture owns responsibility for results, therefore self manages.


    Expenses and Assets
    Covey asked us what we are called in spreadsheets.   He said that in spreadsheet and financial accounting, people are called expenses and cost centers, while things like microphones, tools, and machines are called assets.  He said this is left-over from the industrial age.

    Finding Your Voice
    Covey asked how do you help people find their voice?  You ask them what are they good at?  What do they love doing?  What is your greatest unique contribution?

    The key is finding a voice that meets a human need.

    Inspiration Over Jackass Theory
    The Jackass Theory refers to the carrot and the stick.  Covey asked us what kind of supervisor do you need when you have a job that you are passionate about and is using your talents and you feel you are appreciated.

    People are volunteers.  You want them to contribute their greatest, unique contribution.

    Keys to Effective Large Team
    Covey outlined the keys for effective large teams::

    • Psychologically committed.
    • Accountable to the team / everybody.
    • Culture of results.

    One person may represent the group, but accountability is to the team versus the boss.  Accountability to the team versus an individual is a knowledge worker concept.

    How To Find the Win / Win Performance Agreement
    Covey suggested an approach for finding the Win/Win for teams and organizations in terms of performance:

    1. Help them find their voice.
    2. Find out what individuals are good at and like doing and serves the needs of the business.

    When you have that, you have a win-win.  The key is to have a win/win performance agreement where it is mutually beneficial between the individual and the organization.  The individual should be able to use their full talent and passion (there voice.)

    Information is the Knowledge Worker's Disinfectant
    Covey mentioned that light is the greatest disinfectant in nature.  For the knowledge worker, it’s information.  For a knowledge worker to be effective in a team, they need information, they need the criteria for success and they need to be accountable to the group.

    The Whole Person
    According to Covey, the whole person includes four parts:

    • Body
    • Mind
    • Heart
    • Spirit

    Control-Paradigm to a Whole Person Paradigm
    Covey reminded us that today’s workforce is about directed autonomy.  You manage (things) that can’t choose.  You lead people.  People have the ability to choose.

    The key take aways are:

    • Today’s world is about breaking away from a control paradigm and shifting to one of directed autonomy.  
    • Help people find their voice.
    • You can’t buy the mind, body, heart, and spirit – they are volunteered. 
    • Use all four parts of your nature.  If you take one away, then you’re treating a person as a “thing” that you control and manage.

    Keeping Top Talent
    Covey told us about how Admirals in the Pacific were losing people to better paying jobs.  There was an exception.  Covey got to meet the group that kept their top talent.  The keys to a committed group included:

    • The culture was committed in hearts and minds.
    • The job was fulfilling and meaningful.

    Indian Talking Stick Communication
    Covey shared a technique for improving empathic listening.  It’s the Indian Talking Stick:

    • You give the stick to the other person first. 
    • You don’t get the stick back until the other person feels they are understood.
    • The purpose is not to agree, or disagree, but only to understand the speaker.

    You don’t need to use an Indian talking stick.  You can use any object.  The value of the object is that you don’t get it back until the other person feels understood.

    Industrial Age Concepts
    Throughout the session, Covey made reference to some "industrial age concepts":

    • People are an expense, tools and machines are assets.
    • Supervision is an industrial age concept.
    • One-on-one accountability to a boss.
    • Comparison systems for the basis of collaboration.

    Lighthouse Principles
    Throughout the presentation, Covey referred to some lighthouse principles that govern behavior:

    • Cultivate an abundance mentality.
    • There are four parts to our nature: body, mind, heart, and spirit
    • The whole is greater than the parts
    • Develop integrity; avoid duplicity (Don’t say one thing, but do another and if you make a promise, keep it.)

    Continuum of Communication
    Covey showed us a continuum of communication that moves from hostility and transaction-based communication to transformation:

    1. Hostility
    2. Defensive Communication (Transaction)
    3. Respectful Communication (Transaction)
    4. Synergy, Third Alternative (Transformation)

    Empathic Listening is the No. 1 Communication Skill
    Covey stated that communication is the number one skill in life.  He went on to say that empathic listening is the number one communication skill.   Covey explained that empathic listening is listening within the other person’s frame of skills.   Listening empathically is listening with the other person’s frame of reference.  The key is to listen until the other person feels heard and understood. 

    Empathic Listening Over Telling and Selling
    A satisfied need, no longer motivates.  Covey used the example of air – it’s a satisfied need.  When the other person feels heard and understood, it’s more likely they will listen to you and that you can seek a better solution, that’s mutually beneficial.  You are no longer telling and selling.

    Our Experience is the Lens We Use to Interpret Life
    Covey showed the audience three pictures.   One half of the audience looked at the first picture.  Next, the other half of the audience looked at the second picture.  Then the full audience looked at a third slide which was a composite of the first two slides.  Depending on which of the pictures you saw first, influenced what you saw in this third picture.

    The key take away here was that what you saw was influenced by your experience and that rather that impose your view, first understand the other person’s perspective – there’s a good chance, you’re both right! (This is a good case where the Indian Talking Stick could come in handy.)

    Resolving Conflict By Finding the Third Alternative
    Covey shared a technique for resolving conflict that works for him in 95% of the cases he runs into around the world.  Here’s the key steps:

    1. Put up the two points.
    2. Ask the question, “would you be willing to search for a solution that would be better than what either of us has proposed?”

    The key here is to listen to the other person first and listen empathically.  The proactive part here is that you can choose to listen to the other person first (seek first to understand, then to be understood.)

    Listening to Loved Ones
    One of the audience members asked for advice on counseling a loved one.  Covey responded with the following solution:

    1. Start by saying, “Honey, I have not spent the time to listen to you, all I’ve done is tell you and evaluate.”
    2. Listen in depth; restate to their satisfaction. (Empathic listening)
    3. After they feel understood, you ask, “Have I listened to you?  Are you willing to listen to me, as I have listened to you?”
    4. Find a 3rd alternative.

    The key here that Covey mentioned is that most people will not pay the price of listening empathically.

    7 Habits of Highly Effective People
    Covey shared a slide that framed out the seven habits of highly effective people in terms of private victory, public victory, dependence, independence, and interdependence.

    1. Be proactive.
    2. Begin with the end in mind.
    3. Put first things first.
    4. Think win-win.
    5. Seek first to understand, then to be understood.
    6. Synergize.
    7. Sharpen the saw.

    Habits 1,2,and 3 are the foundation for private victories and integrity.  Habits 4, 5, and 6 are the keys to public victories.

    Peace of Conscience Over Peace of Mind
    Covey made a distinction between peace of mind and peace of conscience.  He explained that integrity is more than honesty.  Integrity means that if you make a promise, you keep it.  If you’re honest, you might have peace of mind, but if you don’t have integrity, then you won’t have peace of conscience.  You have peace of conscience by avoiding duplicity.

    Loyalty to the Absent
    Covey made his point very simply – only talk about people as if they are there.  You can be critical, but speak as if they were there in front of you.  Don’t bad mouth them behind their back and then sweet talk them to their face.  This is a lack of integrity and creates deep duplicity inside you.  This inhibits your ability to have peace of conscience.

    Use I Messages Over You Messages
    Meet with the people you have a problem with directly.  Practice the following:

    1. Let me listen to you first.
    2. Use “I” messages vs. “you” messages.  I messages are “It’s my perception,” “in my experience,” … etc.  You messages are “you are …”

    Genuine Happiness
    Covey said the key to genuine happiness is to develop integrity.  The key to developing integrity is the first three habits (your Private Victories):

    1. Be proactive
    2. Begin with the end in mind
    3. Put first things first.

    Greek Philosophy of Influence
    Covey shared the three parts of the Greek philosophy of influence:

    1. Ethos – credibility, model trust.
    2. Pathos – restate the point of view.  (Seek first to understand …)
    3. Logos – Make your presentation. (… Then to be understood.)

    You Are the Creative Force of Your Life
    Covey challenged us to be a creative force:
    1.     Get out of victimism – You’re not a victim of your circumstances.
    2.    You are the creative force of your life.

    Empathize first.  Grow your circle of influence.  Make tremendous impact.

    The Most Important Thing You’ll Ever Do
    Covey closed with a powerful message we could take away:

    The most important thing you’ll ever do is in the four walls of your own home.

    My Favorite Part of the Session
    While I enjoyed the entire session, my favorite part was getting to meet Dr. Covey.  I shook his hand, I thanked him for helping people find their voice and he signed my post it note (sadly, I didn’t think to bring my Covey books, and all I had was my post it notes.)

    Key Actions
    After the session, I met with Srinath.  We learned a lot so we tried to turn our insights into a small set of key actions.  Here’s what we came up with:
    1. Develop personal / family mission statements and help others to do the same.
    2. Develop empathic listening and help others to do the same.
    3. Find our voices and help others find theirs. 

    Personally, I want to make more use of the Indian Talking Stick Communication technique, particularly at some of my more vibrant meetings.

    More Information

  • J.D. Meier's Blog

    patterns and practices WCF Security Application Scenarios


    We published an updated set of our WCF Security application scenarios yesterday, as part of our patterns & practices WCF Security guidance project.   Application Scenarios are visual "blueprints" of skeletal solutions for end-to-end deployment scenarios.  Each application scenario includes a before and after look at working solutions.  While you still need to prototype and test for your scenario, this gives you potential solutions and paths at a glance, rather than starting from scratch.  It's a catalog of applications scenarios that you can look through and potentially find your match.

    Common Intranet patterns:

    Common Internet patterns:

    One Size Does Not Fit All
    We know that one size doesn't fit all, so we create a collection of application scenarios that you can quickly sort through and pattern match against your scenario.  It's like a visual menu at a restaurant.  The goal is to find a good fit against your parameters versus a perfect fit.  It gives you a baseline to start from.  They effectively let you preview solutions, before embarking on your journey.

    How We Make Application Scenarios
    First, we start by gathering all the deployment scenarios we can find from customers with working solutions.  We use our field, product support, product teams, subject matter experts, and customers.  We also check with our internal line of business application solutions.  While there's a lot of variations, we look for the common denominators.  There's only so many ways to physically deploy servers, so we start there.  We group potential solutions by big buckets. 

    In order to make the solutions meaningful, we pick a focus.  For example, with WCF Security, key overarching decisions include authentication, authorization, and secure communication.  These decisions span the layers and tiers.  We also pay attention to factors that influence your decisions.  For example, your role stores and user stores are a big factor.  The tricky part is throwing out the details of customer specific solutions, while retaining the conceptual integrity that makes the solution useful.

    Next, we create prototypes and we test the end-to-end scenarios in our lab.  We do a lot of whiteboarding during this stage for candidate solutions.  This is where we spend the bulk of our time, testing paths, finding surprises, and making things work.  It's one thing to know what's supposed to work; it's another to make it work in practice. 

    From our working solution, we highlight the insights and actions within the Application Scenario so you can quickly prototype for your particular context.  We then share our candidate guidance modules on CodePlex, while we continue reviews across our review loops including field, PSS, customers, product team members, and subject matter experts. 

  • J.D. Meier's Blog

    patterns and practices WCF Security Guidance Now Available


    Our patterns & practices WCF Security Guidance Project is in progress on CodePlex.  This is our first release of prescriptive guidance modules for WCF Security. 

    How Tos
    Our How Tos give you step by step instructions for performing key tasks:

    Our videos step you visually through key guidance:

    About WCF
    Windows Communication Foundation (WCF) is a service-oriented platform for building and consuming secure, reliable, and transacted services.  It unifies the programming models for ASMX, Enterprise services and .NET Remoting.  It supports multiple protocols including named pipes, TCP, HTTP, and MSMQ.  WCF promotes loose coupling, supports interoperability, and encapsulates the latest web service standards.  With WCF, you get flexibility in choosing protocol, message encoding formats, and hosting.   For more information, see the MSDN WCF Developer Center.

    About the Project
    WCF provides a lot of options and flexibility.  The goal of our patterns & practices WCF Security Guidance Project is to find the key combinations of security practices for WCF that work for customers and share them more broadly.  At a high-level, you can think of the project in terms of these main buckets:

    • Application Scenarios - These are whiteboard solutions for common end-to-end application scenarios.
    • How Tos - These are step-by-step instructions for performing key end-to-end tasks.
    • Building Codes - These are our sets of rules and practices.  This includes Guidelines, Checklists, and Practices at a Glance.
    • Reference - This includes Explained, Cheat Sheets, and Q&A guidance.

    The plan is to incrementally share our guidance modules on CodePlex as we go, then build a guide, then port the guidance to MSDN once it's baked.

  • J.D. Meier's Blog

    Tests for Success


    How do you identify the bull's-eye among your stakeholders?  Nothing's worse than finishing a project and missing the mark you didn't know was there. At patterns & practices, one of our effective project practices is to use "tests for success" to help avoid this scenario.

    What are Tests for Success
    "Tests for success" are the prioritized success criteria that the stakeholder's agree to.  It's basically a set of test cases, that if the project passes, the project is perceived as a success.  They help clarify outcomes and priorities.

    Example Tests for Success
    Here's an example of "tests for success" from one of my projects:

    • Single multi-dimensional information model?
    • Single unified perspective of the product model?
    • Single unified perspective of the content model?
    • Backlog is mapped to the information model?
    • Capability to do comparative analysis and produce “Consumer reports” view of the catalog and the proposed work? (e.g. What’s customer demand? ... What’s our coverage?)

    Stakeholders for the project created and prioritized this list, with prompts from the project team.  This exercise helped clarify a lot of ambiguity as well as do a level set for the team.

    How Can You Use This
    Whether it's a personal project or a project at work, you can create your own tests for success.   I think a small list of the vital few works better than a laundry list.  Phrasing the tests as one-liner questions makes them easy to create and use.  Here's some prompts to trigger your own tests for success:

    • How will the world be a different place when the project is done?
    • How will we know we did a good job?
    • What's the most valuable outcomes for the project?
    • In order for the project to be successful, we need to .... ?

    When you're in the thick of things, you'll appreciate having a small set of criteria to go back to and help keep you and everyone involved on track.

  • J.D. Meier's Blog

    Turning Chickens into Pigs


    Have you ever been on a project where key stakeholders don't have skin in the game, but they have a controlling vote?  This is a bad situation.  It's like multiple backseat drivers, except they won't be there if the car crashes.  What's the solution?  You turn chickens into pigs!

    The Chicken and the Pig
    You may have heard the story about the chicken and the pig.  The chicken says to the pig, "We should should start a restaurant."  The pig asks, "What would we serve?"  The chicken responds, "Bacon and eggs!"  The pig says, "No thanks!"

    The point in the story is the pig's "committed" while the chicken's "involved."

    The Solution
    Recognizing the situation is more than half the battle.  When you've identified that chickens have controlling votes over pigs, your options include:

    • Avoid the situation where chickens are controlling the votes for pigs.
    • Make sure the chickens don't have controlling votes and make it explicit.
    • Turn the chickens into pigs.  You need to move them from involved to committed.  Have them take commitments or dependencies (skin in the game and committed to your success.)
  • J.D. Meier's Blog

    How To Differentiate


    How can you differentiate what you do?  This can be particularly difficult in problem spaces that seem over-crowded.  It helps if you have a frame.  One of my mentors gave me a useful lens for differentiating that helps solve this problem.

    Problem, Approach, or Implementation
    You can differentiate based on problem, approach or implementation:

    • Problem - What problem do you address?
    • Approach - What strategy do you use to solve the problem?
    • Implementation - How do you implement your solution?

    If you differentiate at the problem you solve, it's good to be able to call that out.   If you solve the same problem, but use a different approach, unless it produces a big difference in results, it's probably not worth it.  If you differ only by implementation and the experience or results aren't valued by the customer, again, it's probably not worth it.

    Using the Frame for Differentiation
    First identify whether you differentiate at the problem, approach, or implementation.   Next, determine whether the level at which you're differentiating is worth it.  For example, consider safety among automobile makers.  Volvo's approach to safety stands out.  They work the same problem but differentiate by approach.

    By having clarity around where you differentiate, it's easier to communicate your deltas in a meaningful way to others.

    At Microsoft, when I tackle a problem that's been "solved" before, I use the frame as a lens to quickly find the useful differentiation.  For example, doing security reviews wasn't a new problem.  However, changing the approach by using inspections and building a set of reusable criteria from a team of experts changed the game.  By using criteria based on principles and patterns, and then organizing the criteria within a frame of actionable categories produced exponential results for all of our customers that adopted the approach.  Old problem, new approach, great results.

Page 33 of 45 (1,101 items) «3132333435»