0

We have a well established .NET framework based SAAS web application which supports Oauth2 to multiple providers, and we want to implement the same with SAML/SAML2. The current implementation of Oauth2 does all the necessary steps using resful http get and post calls plus the one redirect.

Looking at existing libraries, they all seem to want changes in "startup.cs" or wherever your startup code is and they add code to web.config. So they are building themselves into the core of your project. We don't like libraries that do that, we don't want to run code that isn't needed and our code has to pass some pretty deep auditing for defense apps, so we'd prefer not to use external libraries from nuget, although we would be prepared to include some libraries from MS if they do not interfere with the app infrastructure (startup and web.config).

Only a small minority of our customers will use SAML since most will use direct logins or Oauth2 providers.

So how can we add SAML with pure restful calls / redirects and not using third party libraries ? I hoped we could find examples where you build up a piece of XML and send it via http post or via a querystring, but after several hours I am not finding this.

TIA

user2728841
  • 1,333
  • 17
  • 32
  • Authentication **should** be built into the core of the project. – Joel Coehoorn Feb 17 '23 at 15:36
  • Customer A authenticates with Oauth with okta,.. customer B authenticates with SAML and duo, Customer C authenticates with Oauth with Azure, Customer D uses a username and password to log in .. do we really want code executing in the app startup or rules in web.config just for customer B ? I'd prefer the obvious logic.. when you need this functionality, call this code. When you don't need it, don't call it. – user2728841 Feb 17 '23 at 16:29
  • If it has to be libraries then I think we will have to create a new web application, redirect to that, from our main app, and that does the SAML and then redirects back. What an awful state of affairs ! – user2728841 Feb 17 '23 at 18:15
  • I've seen it done that way, but it can be challenging because now you have to match up sessions between the two apps. The example is from the small college where I work. We have a library circulation web app written in perl that runs in apache, configured to do SAML SSO to our AD FS server as the IdP. To make SAML work involved installing a separate PHP application to the same apache instance. So again, it can work: but I can also tell you this was the hardest SAML authentication setup I've yet done, and I'm approaching 2 dozen of these now. – Joel Coehoorn Feb 17 '23 at 18:18
  • Thanks. perhaps a sha'd token (jwt or just random string + expiry date). The main app gives a token to the saml app to say please authenticate this user (we don't who yet). Then the saml app does it's stuff with the IdP, then it redirects with a sha of the token back with the saml data and user details then we're ok. I should have the luxury of the same asp.net session so it can remember the token without having to store it anywhere else – user2728841 Feb 17 '23 at 18:34

2 Answers2

2

SAML can actually be quite complicated to implement properly: you WILL want library support for this. Even more, I see this:

we don't want to run code that isn't needed [because] our code has to pass some pretty deep auditing for defense apps

Mostly, this is the right attitude from a security standpoint. There are too many examples now of a threat actor getting malicious code into upstream libraries... thankfully not as much in the .Net ecosystem, but enough generally to be a legitimate security concern. But for authentication specifically avoiding libraries is exactly the wrong approach. It's actually significantly worse for security to try to do this on your own.

In fact, using a library for authentication should make security auditors happier, because it's just so easy to implement authentication code that seems to work correctly — passes all your unit and integration tests and looks like it's working — where in fact you have subtle bugs that result in finding out a year later you were hacked six months ago. Using a purpose-built, battle-tested library helps you avoid that scenario.

I've been saying this since at least 2010. The idea is when a flaw is discovered (because they always exist) it's found on someone else's product first. But because they're using the same library a patch is created, distributed, and applied before your own product ever has a chance to be breached. Unfortunately, the reality is these audits are often as much about ticking the box as cheaply and painlessly as possible as they are about actually improving things, so I understand where it can be hard to get this through.

Personally, I have successfully implemented SAML authentication using the ITfoxtec library for two different apps. However, it's not something I work on often enough to have broad experience to comment on the relative quality of this option vs alternatives other than to say I was able to make it work.

The main thing for this library is the source code is available, and fairly easy to browse and understand, which should further make auditors happy. Moreover, because the source is available with a very permissive license you can fork the project and include the code directly as part of the main build. This should further make it easier to audit.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
1

Just to add to what Joel said, I think you'll find it's more cost effective to use a 3rd party library (either open source or our commercial library) rather than implementing something yourself. Also, security is important, obviously, so it's much safer to use a battle-hardened, proven implementation that's been used in production by many others for many years.

I'm not sure about other libraries, but our SAML library for ASP.NET doesn't require any code in the start-up class or changes to web.config. Perhaps you're referring to .NET 6 etc where's it's common practice to hook into the dependency injection system in the start-up code. In our library, the SAML code is executed only when required as part of a SAML SSO flow so there's no additional overhead for non-SAML authentication.

The SAML protocol is more involved than OAuth2. I suggest taking a look at the SAML v2.0 specification documents to get a feel for the effort involved.

ComponentSpace
  • 1,287
  • 6
  • 9