We have an ASP.NET MVC application used by people from other organisations. Some of the features are accessible via a forms login. Other features are accessible as SHA256-HMAC-authenticated API methods.
We have two clients who are asking for something like SSO for their users:
One client's users currently sign in using WebSeal. None of these users know their passwords - they're all managed by the client through our user management API. We haven't had to do anything special for these users so far, but they say that when we disable TLS1.0 in the near future, their WebSeal setup won't work any more (not sure why since WebSeal seems to support TLS1.2, but I trust they're well-informed).
Another group are asking if they can bypass the forms login page after their users have logged into their own portal.
I'm wondering if we can satisfy both groups by providing an HMAC-authenticated API which returns an auth token for the supplied username, which they can then use to connect to the web site. We would create a role (perhaps called ClientAuthAdmin), and only members of that role (one system user per client) would be authorised to call the API method.
Questions I've asked myself about this, and my own security-novice answers are:
Is it OK to allow one user to get an auth token for another? It doesn't involve divulging passwords. The only harm that I can imagine could be done would be if the auth token was used to perform an action not made by the authorised user. Avoiding that would be the responsibility of the client organisation.
Will this work for our clients? I haven't figured that out yet. They'd have to get the token from our API using whatever internal portal they're using, then attach that as a cookie to their request for one of our web pages. It sounds simple at least, though I haven't figured out the details yet.
My question is: would this be as secure as our existing forms login?