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 architectureHomegrown SOAP web services that allow a developer to connect via SSOSAMLClients 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:Fundamentally, am I going in the right direction? 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 authorizationI'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?I am willing to spend money on a solution as well, is there any other solutions I should be looking into?
Authorization and Authentication using multiple types of authentication in MVC
asp.net mvc;authentication
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.