SAML 2.0

I have been working a lot with SAML recently, which is a protocol for standardizing single sign on (SSO) between sites. A good number of sites and products use SAML as a SSO protocol, including Google Apps and Moodle, important sites to communicate with in my particular case.

I'm working in .NET 3.5, which unfortunately has no built-in support for SAML 2.0, but there are many third-party libraries and references to build your own support for it.

Here are some of the best links I have found for learning SAML.

References

• Google's introduction to SAML SSO
• SAML on Wikipedia
• SAML 2.0 on Wikipedia
• Official specs and documentation for SAML

Examples

• Google App's reference implementation of SAML SSO
• Example SAML requests and responses

F# and Functional Language Respect

I have been experimenting with Microsoft's F# language, their version of ML / OCaml for the .NET Framework. Microsoft recently announced that F# will become an official part of Visual Studio, up there with C# and Visual Basic. I had never really used an ML-based language before, so I was not sure how big the learning curve would be, but I find that my knowledge of Haskell gets me far enough to feel comfortable writing simple programs after looking over the documentation for a few minutes. On top of that, the current pre-release version of F# has near perfect integration with Visual Studio, including an interactive REPL, debugging, and syntax completion. If you are in the market for a good functional language and are in the Microsoft developer ecosystem, F# seems like a great choice.

I'm not sure how much I will use F# at work, if at all, but it is good to see that functional languages are being taken very seriously at Microsoft now. Not only are the developments of F# encouraging, but each new version of C# adds more functional features, and I find myself using those features daily in my work.

Recommended Sites:

• Microsoft F# Development Center

Test Driven Development Best Practices for C#

As I have mentioned before, my company has recently started to use the Test Driven Development style of programming. In order to help us write testable code, I came up with this simple list of best practices for making our C# code base more testable. (Some of the links refer to limitations of Rhino Mocks, a mocking framework for C#, but the rules apply more generally as well.)

To maximize the testability of code, follow these rules:

1. Write the test first, then the code. (PRIME DIRECTIVE!)
   Reason: This ensures that you write testable code and that every line of code gets tests written for it.
   
   
2. Design classes using dependency injection.
   
   See: Intro to Rhino Mocks (see "Creating Testable Web Applications" section) and Dependency Injection Article
   Reason: You cannot mock or test what cannot be seen.


3. Separate UI code from its behavior using Model-View-Controller or Model-View-Presenter.
   
   Reason: Allows the business logic to be tested while the parts that can't be tested (the UI) is minimized.
   
   
4. Do not write static methods or classes.
   
   See: Intro to Rhino Mocks (see "Creating Testable Web Applications" section) and Rhino Mocks Limitations
   Reason: Static methods are difficult or impossible to isolate and Rhino Mocks is unable to mock them.
   
   
5. Program off interfaces, not classes.
   
   Reason: Interfaces can be easily mocked using Rhino Mocks and other mocking frameworks.
   
   
6. Isolate external dependencies.
   Reason: Unresolved external dependencies.
   
   
7. Mark as virtual the methods you intend to mock.
   See: Rhino Mocks Limitations
   Reason: Rhino Mocks is unable to mock non-virtual methods.