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

We frequently help Product Owners and Development Teams 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:

  1. Use a Commercial SAML Component
  2. Use Shibboleth integrated with IIS as your Service Provider
  3. Use an Open Source SAML Library

Option #1 – Commercial SAML Component

A very popular commercial SAML component is available for C# and ASP.NET – ComponentSpace ($499 for a single developer license).

ComponentSpace gives you a software-based SAML Service Provider complete with documentation, examples and support.  The libraries also include a SAML Identity Provider, which is useful for testing.  You can download a free 30-day evaluation here.


  • 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)
  • Free 30 day trial with example Visual Studio projects


  • 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 or 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.  Shibboleth has the capability to fetch metadata from a “feed”.  The commercial and open source SAML libraries for C# and do not have this capability.

Option #2 – Shibboleth Service Provider

Shibboleth is a mature open source SAML Service Provider implementation that integrates with IIS as an ISAPI filter.  The best way to think about Shibboleth is that you are relying on a web server module to handle the SAML authentication.

You would configure Shibboleth to protect a route on your web server (eg. /secure), and when you browse to the “Shibboleth-protected” URL, the Shibboleth ISAPI filter 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.  Shibboleth takes the user attributes from the Identity Provider’s SAML Response and sets Server Variables.  In your application, you would check the value of the Server Variables in order to make an access control decision.


  • 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


  • 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

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 either missing key features of the SAML protocol (eg. logout, decrypting assertions, etc.) or are complex and come with a lot of dependencies.

You may be able to get away with using an open source SAML SP implementation, but your Dev Team will likely be spending valuable time implementing missing SAML functionality, and your total cost of ownership will be higher than if you just purchased a commercial SAML component.

Recently there have been improvements in this area, and we can recommend looking at the Sustainsys/Saml2 SAML library to see if it will meet your needs.

There are two other open source SAML SP libraries that we have worked with, but we do not recommend using these libraries in production because they are missing key features:

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.

Shibboleth SP Install on Amazon AMI Linux

Here is a recipe for installing the Shibboleth Service Provider on Amazon AMI Linux and integrating with the built-in Apache.

Install Prerequisites

Use the following command to install all of the prerequisite tools:

  • yum install automake boost-devel chrpath doxygen gcc-c++ groff httpd-devel libidn-devel openldap-devel openssl-devel redhat-rpm-config stunnel unixODBC-devel
  • yum install rpmdevtools rpm-build

*Note: the above steps install Apache 2.2

Manually Install Shibboleth Dependencies via SRPM

You will want to grab the latest SRPM files that match your version of Amazon Linux.  This recipe is based on Amazon Linux AMI release 2015.09, which is compatible with RHEL 6 SRPMs.  The instructions below are based on the Shibboleth SRPM install instructions.  If you grab newer libraries, you will need to adjust the file names in the recipe.

Use following sequence to build and install all prerequisites.  There are a lot of dependencies, so the order of the steps below matters.

  1. log4shib
  2. xerces-c
  3. xml-security-c
  4. curl-openssl (on RHEL/CentOS 6.x and later)
  5. xmltooling
  6. opensaml
    • wget
    • rpmbuild –rebuild opensaml-2.5.3-1.1.el6.src.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/libsaml8-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/libsaml-devel-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/opensaml-schemas-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/opensaml-debuginfo-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/opensaml-bin-2.5.3-1.1.amzn1.x86_64.rpm
  7. shibboleth
    • wget
    • rpmbuild –rebuild –without builtinapache -D ‘shib_options –with-apxs24=/usr/sbin/apxs –with-apr1=/usr/bin/apr-1-config –enable-apache24’ shibboleth-2.5.5-3.1.el6.src.rpm
      • **Note: this is an important step to make sure you build the Shib Apache module to work with Apache on AMI Linux.  You may need to adjust the path for apxs and apr-1-config
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/shibboleth-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/shibboleth-devel-2.5.3-1.1.amzn1.x86_64.rpm
    • rpm -ivh /usr/src/rpm/RPMS/x86_64/shibboleth-debuginfo-2.5.3-1.1.amzn1.x86_64.rpm
  8. Copy the Apache config for Shibboleth
    • cp /etc/shibboleth/apache22.config /etc/httpd/conf.d/shib.conf
  9. Configure Shibboleth
    • Edit /etc/shibboleth/shibboleth2.xml to configure your SP and add your IdP metadata
  10. Start the shibd process
    • /usr/sbin/shibd

InCommon Federation Metadata Config for Shibboleth IdP V3

We have been helping customers upgrade from Shibboleth IdP 2.x to V3, and we wanted to highlight some common configuration questions we have received.

If you want to configure your Shibboleth IdP V3 to participate in the InCommon Federation, you need to add some configuration to your metadata-providers.xml file that may not directly translate from your Shibboleth 2.x configuration.

First, make sure that you have downloaded and verified InCommon’s metadata signing cert and copied the signing cert to your ${idp.home}/credentials/ directory.

Next, edit your metadata-providers.xml file and add the following code before the closing </MetadataProvider> tag.

<MetadataProvider id="ICMetadata"xsi:type="FileBackedHTTPMetadataProvider" refreshDelayFactor="0.125" maxRefreshDelay="PT2H" httpCaching="memory"
backingFile="%{idp.home}/metadata/incommon-metadata.xml" metadataURL="">

  <MetadataFilter xsi:type="SignatureValidation" certificateFile="${idp.home}/credentials/inc-md-cert.pem" requireSignedMetadata="false">
<MetadataFilter xsi:type="EntityRoleWhiteList">

Contact us if you need help planning your Shibboleth IdP 2.x to V3 upgrade.

Killing an Active Office 365 Session

There is one key administrative feature that seems to be missing from Microsoft Office 365 – the “kill switch” that disables an Office 365 account and kills all active sessions (browser, ActiveSync, etc.).  Without official guidance from Microsoft, there has been speculation from Office 365 Admins on the best approach for disabling access to an Office 365 account in the event of a breach or security issue.

We wanted to share a best practice for killing active Office 365 sessions that we learned through our contacts at Microsoft and feedback from the UC Davis Office 365 email list.

  1. Change the password on the mailbox
  2. Remove the mailbox using the “Remove-Mailbox” command
    • For example:
      Remove-Mailbox -Identity "John Rodman"
  3. Wait 15 minutes
  4. Restore the mailbox

Restoring the mailbox is an important step in this process, since the mailbox will be automatically deleted if you do not restore it within 30 days.

Shibboleth IdP V3

Shibboleth IdP version 3.0 was released on December 22, 2014.  Detailed documentation on Shibboleth IdP v3 can be found on the Shibboleth wiki.

With the Shibboleth Consortium expected to announce the end date for the V2 Identity Provider soon, it is worth moving to Shibboleth IdP V3 for new deployments.  If you are running Shibboleth IdP V2, you may want to start planning your upgrade to V3.

System Requirements

You can find the most up-to-date list of system requirements here.  While there are no specific operating system requirements, Linux, OS X and Windows are recommended.  Oracle Java or OpenJDK versions 7 and 8 are the supported Java environments, and only Tomcat 8.x and Jetty 9.2.x are officially supported servlet containers.

What’s New in IdP V3?

Internet2’s recent press release does a good job of summarizing the key features of Shibboleth IdP V3:

  • uApprove integration, which provides individuals with information about the attributes requested by service providers and gives individuals the ability to control attribute release
  • Built-in support for CAS, which means IdP V3 can handle both on-campus SSO and federated authentication to access external SAML-protected services
  • Ability to support multiple algorithms for signing and encryption simultaneously, allowing organizations to increase the security of their transactions without compromising compatibility with older systems
  • Built-in next generation federation features such as the emerging Metadata Query Protocol, allowing on-demand metadata lookup that is replacing the need to compile ever-larger metadata aggregates
  • Support for internationalizing user interface and error messages

The Shibboleth wiki has more detail on all of the changes you can expect from IdP V3.

We are excited about Shibboleth IdP V3, and we are ready to help you plan your upgrade or new installation.  We have flexible support options to help you get past configuration issues as well as comprehensive support options for your IdP environment.

Keep an eye on our blog for more articles to help you make the transition from Shibboleth IdP V2 to V3.

Advanced Office 365 ProPlus Troubleshooting

In our previous blog post, we provided you with advice for troubleshooting Microsoft Office 365 ProPlus login and activation issues.

We wanted to share some advanced troubleshooting techniques from Microsoft Support Engineer Keith Cronsell.

If you turn on logging while troubleshooting as issue, don’t forget to turn it off after you have resolved the problem.

Troubleshooting Authentication/Sign-in/Activation Errors

The following steps will enable logging.  Once you have logging enabled, you should try to compare a “working” attempt against a “non-working” attempt to compare the results.

Set the following regkey to enable TCOTrace logs.

To do this, launch cmd as administrator and run the following command:

reg add HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Debug /v TCOTrace /t REG_DWORD /d 1 /f

Then try the activation process again from the Sign-In screen. Once the error occurs collect the following:

  1. Collect logs from %temp%
    • Office.log
    • <appname>.exe.log (where <appname> is the name of the application used for the Sign-In attempt, for example, Excel.exe.log or Winword.exe.log)
  2. Remove the regkey added.  To do this, launch cmd as administrator and run the following command:
    • reg delete HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Debug /v TCOTrace /f

Troubleshooting Office 365 Install/Update Failures

The following steps show you how to enable verbose logging to help you troubleshooting Office 365 install/update failures.

To enable verbose logging, launch cmd as administrator and run the following command:

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3

ULS log file is created both in the %temp% folder and the %windir%\temp folder.  The file name is of the following format:


For example Keith-201420141610-1434.log.  Once these logs have been retrieved and analyzed, verbose logging should be disabled by running the following command from an administrative command-prompt:

reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /f

The log output is in ULS format.  Opening the log file in Excel will help you with filtering the data.  First, you want to look for is the term “unexpected”.  You can look for “Fail” and /or “Error”

When Attempting to Install Office 365 Directly from the Office Portal

Most end user issues with installing/activating Microsoft Office 365 from the Office Portal are proxy/firewall related.  Follow the steps above to review log files.

Fiddler and Process Monitor are also great tools to use for troubleshooting Office 365 ProPlus installation and activation errors.

If possible, try to test using a less restricted proxy/firewall.  If the activation is successful on another network, you may need make adjustments to your proxy/firewall settings.

The following article can help you with determining the IP address and URL exceptions you might need to add:

Start by white listing or adding exceptions for the IP addresses and URLs under “Office 365 ProPlus”.  If you continue to have problems, add the URLs under the “Office 365 portal and identity” section.

If still have problems, try the following:

Open the command prompt (run as administrator), and use the following command to import the manual proxy settings from IE:

netsh winhttp import proxy source=ie

Now rerun the install/update

To reset winhttp back, run the following command:

netsh winhttp reset proxy

Most failed installs directly from the Office portal that are proxy related, usually fail pretty quick and usually with an error like this:

“Sorry, we ran into a problem Go online for additional help. Error Code: 30174-4.”

Or When attempting to update a client that is looking to the Office portal for updates will get something like this:

“Something went Wrong: We’re sorry, we ran into a problem while downloading updates for Office. Please check your network connection and try again later. Error Code: 30088-28 or 30088-27”

Additional Help

IDM Integration has experience with all aspects of helping organizations roll out Office 365 including SSO integration with ADFS and Shibboleth, developing rollout and migration plans, and troubleshooting Office 365 issues.  Contact us if you’d like help with your Office 365 implementation.

Microsoft Office 365 ProPlus Troubleshooting Guide

When Microsoft released Office 365 ProPlus to students as part of their Student Advantage program, it seemed like Microsoft forgot to provide IT support staff with a troubleshooting guide.

With Office 365 ProPlus becoming available as a free download for faculty and staff, it’s even more critical for IT support staff to understand how to troubleshoot end user authentication and activation issues.

We wanted to share some tips to help you with troubleshooting Office 365 ProPlus and to help you achieve a successful Office 365 ProPlus rollout.

Supported Platforms

Make sure your end users understand which platforms are supported by Office 365 ProPlus.  This will help you cut down on calls from folks trying to install Office ProPlus on unsupported platforms like Windows Vista.

Office Online might be an option for unsupported operating systems, but make sure to use an Office 365 supported browser.

Troubleshooting Tips

  • The first troubleshooting step, especially for mobile devices like tablets or laptops, is to check the system clock.  If your organization uses ADFS for authentication, and the device’s system time is not syncing with NTP, chances are good you will see an activation error.
  • Use Microsoft’s Remote Connectivity Analyzer tool to help narrow down issues that might be related to a specific ISP.  Connectivity issues can also be a factor in authentication and activation issues.
  • Microsoft has published a good support resource for troubleshooting Office 365 ProPlus error messages.  This resource can be provided to end users as a self-help guide.
  • Use Microsoft’s “Fix It” tool to completely remove Office 365.  This tool is especially important for Macs, where users often try to remove Office by deleting files from the Applications folder.
  • Being able to see the error from the end user’s perspective is essential for troubleshooting Office ProPlus issues.  We  recommend using a remote desktop access software solution, which can help you perform advanced troubleshooting procedures.
  • Not everyone can afford it, but Microsoft Premier Support is highly recommended to get the best possible support from Microsoft.
  • If you can’t afford Microsoft Premier Support, you can still engage with Microsoft experts on the public Yammer network for Office 365.  If you are in higher-ed, the UC Davis Office 365 email list is an excellent resource.

Additional Help

IDM Integration has experience with all aspects of helping organizations roll out Office 365 including SSO integration with ADFS and Shibboleth, developing rollout and migration plans, and troubleshooting Office 365 issues.  Contact us if you’d like help with your Office 365 implementation.

Configuring Microsoft IIS with multiple Shibbolized websites, using lazy sessions

We recently solved a Shibboleth problem for a customer who had Microsoft IIS, with multiple Shibbolized web sites using lazy sessions, and we wanted to share the solution.


The system worked correctly when Shibboleth was activated by browsing to the protected path in the RequestMap.  The application needed to support multiple login methods, so the lazy session initiation was used when Shibboleth requested at the beginning of the user session (see

This session initiator for the SP that was configured as the override would form the SAML request as if it was the default application.

The original configuration in the RequestMapper:

 <Host name="">
 <Path name="Default/sso" authType="shibboleth"
 requireSession="true" applicationId="access"/>

The updated configuration in the RequestMapper:

<Host name=""
 <Path name="Default/sso" authType="shibboleth"
 requireSession="true" applicationId="access"/>

We found through the Native.log file that the ISAPI module was not using the correct applicationID for the requests outside the path in the Path statement.  Adding the applicaitonID at the host level with no other requirements for a Shib session let the application override work.  This allowed the site to work without forcing Shibboleth auth, but allowed the ISAPI module to relate the Session call to the correct application ID.

We suspect that the combination of Microsoft IIS with multiple Shibbolized websites, using lazy session initiation is rare, but since we couldn’t find any documentation on this specific setup, we thought we’d share our solution.

IDM Integration Joins InCommon Affiliate Program

IDM Integration has joined Internet2’s InCommon Affiliate Program. IDM Integration (IDMI) helps customers build identity management solutions. From helping a commercial service provider overcome a single Shibboleth or SAML issue to helping an organization develop a comprehensive SSO environment, IDMI specializes in open source software integration and support. The company provides support for a wide variety of SSO layering technologies and custom integrations with ERPs, portals, learning management systems and other software systems.

“We are pleased to have IDM Integration join our Affiliate Program,” said Klara Jelinkova, senior associate vice president and chief information technology officer at the University of Chicago and chair of the InCommon Steering Committee. “We value their experience in higher education and with some of the key technology used by InCommon participants.”

The InCommon Affiliate Program provides the research and education community with a way to safely and efficiently connect with partners that can help build the necessary underlying infrastructure that supports federated identity and access management.

“We started IdM Integration because we saw a need for commercial Shibboleth support,” says Dave Alexander, one of the partners in IDMI. “We’ve been working behind the scenes with service providers to help them federate with InCommon, so we’re excited to finally join InCommon as an affiliate. We specialize in providing support and professional services for Shibboleth, and we are looking forward to helping higher ed and K-12 institutions realize the value of implementing federated authentication.”

As a way of celebrating joining the Affiliate Program, IDMI is offering InCommon participants a $100 discount on its most popular service, the Shibboleth Health Check. The service ($400 with the discount) includes two hours of phone consultation followed by two hours of research and follow-up to help resolve issues in the Shibboleth and single sign-on environment. The offer is good through October 31, 2014. Email for more information.

About IDM Integration
Since 2007, IDM Integration has been solving identity management problems. Whether we are helping customers overcome a single technical issue, or are developing comprehensive identity management solutions that integrate with existing systems, we thrive in problem solving. In addition to problem solving, we also provide support and training to ensure continued success for our clients. We support a wide variety of organizations, including corporate, nonprofit and academic, with a strong focus on commercial service providers. For additional information, please visit

About InCommon
InCommon®, operated by Internet2®, serves the US education and research communities, supporting a common framework of trust services, including the US identity management trust federation for research and education, a community-driven Certificate Service, an Assurance Program providing higher levels of trust, and a multifactor authentication program. InCommon has more than 600 participants, including higher education institutions and research organizations, and their sponsored partners, making federated identity available to more than 7.8 million individuals. For more information, see and