Lately we have had a number of questions in reference to how SSO is supported within RXD. Technically, SSO is not something that is or isn't supported with RXD -- it's more a concern of your own application after people reach it. We have had a few customers discuss the use of SSO in their applications, and at least one or two who are using it. However, there are some limitations/gotchas that can come into play.
Primarily, the issue boils down to the fact that we'll be loading your contentUrl (and presumably any SSO handshake pages) inside a frame by default. That frame will be inside a page from the host LMS, most likely, and so the top-level page will be on a different domain. Many SSO providers will have content security headers that do not allow their pages to be loaded inside an iframe. So that's the first barrier. Even if it does allow that, then the next potential issue is any cookies it might set or look for, since browsers will consider it as a 3rd party context and block them.
So for SSO to work well, you'd have to deal with those two issues. Since the RXD files are hosted by you, you could modify them to try and accommodate this. The big one would likely be having the contentAPI.html page open your content URL in a separate window, so that the iframe usage isn't an issue. Maybe it does that only for the SSO handshake and then goes back to the iframe, or it just causes a new window for the learner to experience the course. That's obviously not the ideal launch behavior in many cases, especially on mobile.
As you can see, it's not just a straightforward out of the box situation. There are even more possibilities, even modifying the template stub package, if need be, but any solution will require some effort on your part.
In many cases where we've discussed SSO, the customer just ended up going a different route and not using SSO because of these issues. But it should be possible to make it work.
If you have any specific questions, please feel free to send us a message at firstname.lastname@example.org.