Adding SAML Authentication to your C# or ASP.NET Application

We frequently coach Product Owners and Development Teams on how to add SAML 2.0 authentication to C# and ASP.NET applications, and we wanted to share an overview of what is involved with moving from username/password based authentication to single sign-on via SAML.

This article is not meant to be an in-depth tutorial on the SAML authentication protocol.  We give you an overview of the different implementation options and trade-offs as well as addressing common questions about the effort required to turn your C# or ASP.NET application into a SAML Service Provider.

There are three main approaches to adding SAML authentication to a C# or ASP.NET application – using a commercial SAML component, using Shibboleth as your SAML Service Provider integrated with IIS or using an open source SAML library.

Option #1 – Commercial SAML Component

There are two popular commercial SAML components available for C# and ASP.NET – ComponentSpace ($499 for a single developer license) and ComponentPro’s Ultimate SAML ($299 for Standard Edition single developer license).  Both of these libraries give you a software-based SAML Service Provider complete with documentation, examples and support.  These libraries also include a SAML Identity Provider, which is useful for testing.  You can download a free evaluation version of both libraries.

Pros:

  • You will not have to implement any of the SAML protocol in your application
  • Commercial support and software updates are available
  • Test IdP is included
  • Ideal for SaaS applications (i.e. if you are not using IIS to host your app, your app is multi-tenant and/or your want to implement self-service for users to add their IdP metadata)

Cons:

  • You could say cost is a con, but going with a commercial SAML component is typically more cost effective than trying to adapt an open source SAML library or writing the SAML authentication code by hand
  • If your application is redistributed (eg. white labeled), you need to read the license terms carefully

Other implementation considerations:

  • If you are selling your app to higher-education customers, you may want to pick Shibboleth as your SAML Service Provider solution because it is widely used in higher-education, and it will likely save you some headaches

Option #2 – Shibboleth Service Provider

Shibboleth is a mature open source SAML Service Provider implementation that integrates with IIS as an ISAPI filter.  You protect a location on your web server (eg. /secure), and when you browse to the “Shibboleth-protected” URL, the Shibboleth web server module is triggered and takes care of all of the SAML authentication steps.  Control will only be passed to your application after a successful IdP authentication, and in your application, you will look for Server Variables to get information about the user who logged in.

Pros:

  • Shibboleth is open source software, so there are no license costs
  • Shibboleth is ideal for situations where you run your own IIS server, and you do not have a requirement to allow self-service configuration changes
  • Shibboleth is the preferred SAML Service Provider for Identity Federations like InCommon
  • A Shibboleth implementation could save you time over a software based SAML service provider implementation and might be the best approach if you have legacy software that you need to SAML-enable.  The only code modification required would be to look for Server Variables set by Shibboleth after a successful IdP login
  • Commercial support for Shibboleth is available

Cons:

  • Shibboleth uses configuration files.  The Shibboleth Service must be restarted when the config files are updated
  • Shibboleth is Java based and can be a bit of a memory hog when running on Windows, especially if you join an Identity Federation or turn on debugging
  • Advanced Shibboleth configurations can be a little tricky to implement and may require support

Implementation Considerations:

  • You will likely need a test Identity Provider.  TestShib is one available option

Option #3 – Open Source SAML Service Provider Libraries

We typically do not recommend using the available open source C# and ASP.NET SAML Service Provider libraries for production implementations.  The available open source libraries are typically missing key features of the SAML protocol (eg. logout, decrypting assertions, etc.).  You may be able to get away with using an open source SAML SP implementation, but your Dev Team will likely be spending valuable cycles implementing missing functionality, and your total cost of ownership will likely be higher than if you just purchased a commercial SAML component.

If you want to experiment with open source SAML Service Provider libraries, these are two that are easy to work with:

Implementation Expectations

Here is the overall implementation approach that we recommend:

  1. Select an implementation approach (commercial SAML component or Shibboleth Service Provider)
  2. Build the Service Provider and test things out in your development environment using a test Identity Provider
  3. If everything is working as expected, start working with your external customer’s Identity Provider

There are a few other details you may want to think about when planning your SAML Service Provider implementation:

  • User provisioning and de-provisioning
  • Logout behavior
  • Authentication flow – Identity Provider initiated or Service Provider initiated
  • Multi-tenancy
  • Mobile app use cases

Time and Cost

As a Product Manager, you want to know the bottom line for a SAML Service Provider implementation so you can set budget and timeline expectations with your stakeholders.  On the consulting side, we typically bid out this work at four hours or less, but the actual time to implement SAML authentication in your custom C# or ASP.NET application depends on a lot of factors like developer cycles and the responsiveness and capabilities of your external customer’s Identity Provider Admin.  The cost of the SAML implementation itself depends on the solution you select.  If you have developer resources available and a responsive IdP Admin, you can realistically implement a SAML Service Provider in less than a week, but a two-week implementation time frame is ideal.

Support for your SAML Service Provider Implementation

We have helped hundreds of clients succeed with adding SAML authentication to their custom C# and ASP.NET applications.  We can help you plan your SAML Service Provider implementation and guide you through each step of the way including sitting in on calls with your external customer.  Contact us to schedule a consultation.

SAML Authentication for Mobile and Thick Applications

We have been working with customers to help add SAML authentication to thick and mobile applications.  Since SAML is a web-based authentication flow, and not many SAML Identity Providers support the SAML Enhanced Client or Proxy (ECP) profile, the best option for adding SAML authentication to iOS, Android and thick applications is to use an embedded web browser.

Okta has published a good example of the embedded web browser approach for SAML authentication to an iOS application.  In Okta’s example OAuth is used to impersonate the logged in user after a successful SAML authentication, but this extra step might not be necessary depending on your use case.

The diagram below shows a simplified version of the authentication flow without the extra OAuth step.  Note that a SAML Service Provider is required as part of this architecture, and this approach will not work well if the customers SAML Identity Provider is hidden behind a firewall.