Authorization and Authentication using multiple types of authentication in MVC

Question

Currently I am managing a team where we're building a new SaaS application.

The way it is currently structured is that we have a solution that has our business logic and data, and a solution that holds our website (and related projects)

In our current user base, there are clients that use different types of authentication:

• username/password using the aspnet membership architecture
• Homegrown SOAP web services that allow a developer to connect via SSO
• SAML

Clients may have different settings for logging in, but users within the clients log in the same way. The big challenge with our legacy system is that these are somewhat 'hacked' together and very hard to manage. I want to make sure we are much more scalable for the future.

I've looked into claims-based authentication using the MVC framework and understand that pretty well, so I'm confident our team can build the framework to support it. My challenge is with the STS (identity server), so I have a few questions:

1. Fundamentally, am I going in the right direction?
2. What system owns the knowledge of where a user should be authenticated? I would suspect the STS because that would mean the claims-based system can truly not worry about authentication or authorization
3. I've looked into OpenAM, OpenIDM and IdentityServer for the STS, but cannot really figure out how to plug them in. Are these even STS systems?
4. I am willing to spend money on a solution as well, is there any other solutions I should be looking into?

Answer 1

This has been sitting for a while, and I figured to answer my own question since we've solved this problem by now...

We decided to convince those clients that were using the homegrown SOAP services to utilize SAML, and we partnered with Ping Identity to help us out with the SAML component as we weren't experts.

As for our design, we were able to keep it relatively simple: Some SAML clients were also in need of a username/password authentication type for certain users, so we designed both a connection for SAML as well as for username and password.

We also decided to go with an IdP only approach, which so far, hasn't been an issue.