My 2013 devLink Abstracts

04.02.2013 12:40 by kbeckman | Comments

After a little bit of prodding from a friend and colleague of mine, I submitted a couple of abstracts for talks at devLink 2013. I’ve been thinking about submitting some talks for about a year now. Well, now I don’t have to think about it anymore – but I might have some prep work to do!


Introduce Ruby to Your .NET Environment

[Intermediate to Advanced]

Interested in Ruby, but so far have only tinkered with it at home in your free time? How about at work? Nope… “We’re a .NET shop. …and IronRuby hasn’t had a release since early 2011. Isn’t that project dead?” Now there’s no need for excuses and no need for a Ruby implementation that runs on the CLR. This session provides some real-world examples proving the benefits of using Ruby alongside your .NET environment and helps make the case to include Ruby as part of your development toolkit.

This session includes demos, discussion and Github projects covering the following:

  • Use Ruby (in combination with PowerShell, Albacore, MSBuild and WebDeploy) to streamline your Continuous Integration and code deploy process. Build your code; exercise it with tests; and package/deploy it all without writing a single line of MSBuild XML.
  • Build a stronger relationship with your QA Team by introducing Ruby as the scripting language of choice for integration test automation. You’ll make everyone’s job easier and make automated integration testing a first class citizen in your development process.
  • Tired of spending an afternoon setting up a production or test server? Are your base virtual machines chronically outdated? Use Ruby code and Opscode Chef to bootstrap your servers and use code to setup your servers instead of doing everything manually. Infrastructure as code!


Demystifying Single Sign-On


Single Sign-On – SSO… If you’ve considered single sign-on or identity federation for your organization, those three letters are probably better rearranged – S.O.S. This session will help you sort out all the acronyms and protocols so you can start in the right direction to a successful implementation. We’ll take a look at Windows Identity Foundation and Windows Azure Active Directory (formerly Access Control Service) and how they fit in the overall solution.

This session covers:

The Basics…

  • Token Issuers and Relying Parties (with demo)
  • Comparison of WS-Federation, OAuth and SAML-P
  • SAML AuthN Token Overview
  • Dissection of WS-Federation Web Requests

Advanced Topics…

  • Identity Federation with Trusted Organizations (with demo
  • Important Architecture Considerations
  • Social vs Corporate Identity


What do you think? Do either of these sound interesting enough to make the cut? I ‘m hoping so… Either way, speaking or not, I’ll see you in Chattanooga in August!

omniauth-wsfed v0.2.0 Release

03.18.2013 03:39 by kbeckman | Comments

Recently, I pushed the official second release (v0.2.0) of omniauth-wsfed to omniauth-wsfed is a WS-Federation and WS-Trust strategy for OmniAuth enabling integration with Windows Azure Active Directory (formerly Access Control Service), Active Directory Federation Services (ADFS), custom Identity Providers built with Windows Identity Foundation (WIF) or any other Identity Provider supporting the WS-Federation protocol. Specifically, the 0.2.0 release contains several enhancements related to SAML token validation and WS-Trust + WS-* field validation as well as an overall cleaner and more thoroughly-tested codebase (see the release notes or Github repo for complete details).


Almost four weeks after the release, reported just over 600 downloads (all time, for all versions) and 124 downloads for the new version. Well… Not bad I guess, but definitely not the type of numbers that get your gem recognized on Ruby Toolbox. Reading between the numbers however, there are a couple of positives – a) At the time of this post there were 124 downloads of the new version and only a couple of those were from my current project; b) there are definitely other developers using it! Only a couple of those downloads were related to my current project as I’m in the middle of a refactor effort to organize all enterprise AuthN logic into a Rails engine shared by all applications. Once the engine is finished, the download count should increase quite a bit as it gets promoted through our test environments and onto all of the developer installations. Overall, it’s not a bad start since single sign-on and identity federation for enterprise applications are problems more commonly solved by large corporate codebases written in Java or C#. Most times, Ruby projects are solving this problem with OAuth and using well-established social Identity Providers such as Google, Facebook, Twitter, etc.

Building Some Street Cred…

So why all the information for a Ruby gem targeting such a narrow problem space? Well for starters, omniauth-wsfed finally reached a state where I felt comfortable openly promoting it instead of just using it on internal client projects. I had been thinking about promoting it for a while, but felt the library needed just a little more polish. Additionally, I read a recent post on you’ve been Haacked that finally gave me the motivation to write this post. In the post, Phil Haack discussed his opinions about establishing trust for open source packages on NuGet. Haack discussed several possible options including package signing and using custom NuGet identity verification; but arrived at the conclusion that you’re going to get the most for your effort by simple, established techniques such as social identity verification, download counts and grass roots promotions like the one you’re reading now… :-)


The interesting part about the article was that it doesn’t just apply to NuGet open source packages targeting the .NET Framework. It applies to open source packages in general – whatever the language. Bottom Line: if you’ve written something that you think would be useful to others, promote it; talk about it; encourage others to contribute.

Trust Me… I Have Badges

Aside from the suggestions in Haack’s post, there are some great options for Ruby projects (either completely free or free for open source projects) that can help establish additional credibility for your project. Each of these services come with their own “badges” for display in your Github README calling attention to the fact that you and your contributors are committed to quality. If you haven’t noticed, these are starting to pop up on more and more popular Ruby Github projects. Now that there’s an omniauth-wsfed release I’m proud enough to promote, I got curious about these services and went investigating…


I’ve added these services…

  •   Code Climate – a code quality service for Ruby repositories that tracks metrics such as duplication, code churn and method complexity. Code Climate requires absolutely no effort other than pointing it to your Github repo. 
  • – a cloud-based, continuous integration environment for open source projects supporting many languages including C, C++, Java, Perl, PHP, Python, Ruby, etc. Travis-CI is incredibly easy to setup and requires only a Github account link and a YAML configuration file. Specifically for Ruby projects, Travis-CI is capable of continuous integration against ALL popular Ruby implementations – an insanely useful feature because you can validate your code under conditions and  in platforms that you might otherwise never use.
  •   Version Badge – as long as you’ve released a gem on, Version Badge will provide a badge indicating the most recent version number.

I’m considering these services…

  • Gemnasium – a service that evaluates your project in terms of its dependencies. Projects are scored on whether or not their dependencies are up-to-date and the service notifies you if any new dependencies are available to test with.
  • Coveralls – a code coverage service for Ruby and Python projects that integrates with Travis-CI.

I Want to Hear from You!

One final thing I wanted to call out is the importance of full disclosure in open source projects. It’s extremely important to disclose any known issues (whatever the severity) as well as the project roadmap to potential users of your software. Awareness for known issues before being discovered accidentaly by your consumers will reduce the overall friction of adding your OSS project as a dependency. Personally, I feel much better about acquiring a dependency on a project even if it has some issues as long as I’m aware of them (and how they might affect me) and know the author(s) are actively working on a resolution. Github Issues are a great way to track these details. You can checkout omniauth-wsfed’s issues / roadmap here.

Getting Up-to-Speed with WS-Federation and WS-Trust

09.04.2012 12:58 by kbeckman | Comments

As part of a recent client request, I’ve been asked to provide a list of resources that an organization can use to become familiar with the technologies and protocols behind enterprise Single Sign-On (SSO) and Federated Identity. Single Sign-On between enterprises is a difficult topic, especially when you get to scenarios beyond the initial user authentication. Trust me, there’s a lot more to think about organizationally than just accepting authenticated users from other security domains. The topic of Federated Identity forces organizations to think of users in terms of a global identity rather than a single account in some enterprise application. Users from the local security domain may or may not be treated differently than users from trusted partners. Application authorization rules may differ based on where your user actually authenticated…


The protocols at the core of enterprise SSO are WS-Federation and WS-Trust. At a high-level, WS-Federation defines the transport mechanism for security tokens and WS-Trust defines the procedures for signing, encrypting, validating and renewing authentication tokens. Another popular protocol is SAML 2.0 / SAML-P. [Sorry for the Wikipedia links… I have a better list of resources shortly.] Without getting into the details, there are a lot of functional similarities between WS-Fed and SAML-P… However, the differences are painful enough that we’re going to leave the SAML story for another day (or hopefully never).


Microsoft’s implementation of WS-Federation comes in the form of Windows Identity Foundation (WIF) – a subset of the .NET Framework that contains the types and classes for managing identity. Once a standalone extension to the .NET Framework, WIF is now included in the mscorlib. Below are some valuable resources to help you get started with WS-Federation, WS-Trust and WIF.


For Business Folks [and Developers Before They Start Developing]…

  • Understanding WS-Federation – This is an MSDN article from back in 2007 (pre-WIF) that describes WS-Federation and it’s sub-protocols (WS-Trust, WS-Security, WS-SecurityPolicy). Brace yourself… The article leads off with a copyright notice and never really recovers.
  • A Guide to Claims-Based Identity and Access Control, 2nd Edition – In my opinion, this is the best resource for explaining SSO and Federated Identity across enterprises. With each chapter, the authors setup an enterprise scenario and explain the interactions required by participating organizations to accomplish SSO. More importantly though, this book goes into detail to explain the business problems solved by SSO implementations. Developers will get a lot from this too as it touches on all of the Microsoft technology offerings that are either necessary or helpful in pulling off SSO – ASP.NET, WIF, Active Directory Federation Services 2.0, and Windows Azure Access Control Service.

For Developers…


For ‘Only the Lonely’

If you haven’t gotten your fill from the resources above, you can always take a look at the official OASIS protocol specs. Although I don’t advise this unless you’re working on your own framework or plug-in, etc.