My organization choose SSO to protect our knowledge base. We're finding, however, that there are a lot of issues with the SSO, in part because we have several different platforms that clients can purchase and therefore can access Community. The biggest issues with SSO however are:
The issue is this, our organization doesn't want just anyone getting access to the TKB. If we do away with SSO, we can funnel new users into a role that gets changed, but it's a lot of work and we have users all over the world and not enough man power to have someone in there 24/7 confirming that the user is in fact a client and then updating the role.
So my question, has anyone else come across this issue? If so, what have you done? How are you able to authenticate a client and not just risk letting anyone (competitors) into your knowledge base?
A little over a year ago, we posted a question in Strategy but never received a response ...
We have had SSO now for about 15 months, but we need to turn it off, due to a change in company strategy. We've reached out to Lithium Support without success.
Can someone from Lithium please address this question? A year without a response, on an issue that I'm sure multiple companies have, is way too long to wait for an answer.
Thank you! Appreciate the help!
It's a difficult position for the community team to be in when knowledge base content is required to be gated, and the SSO implementation isn't optimal or doesn't exist. My personal opinion is that content that provides support to customers and helps improve their experience should be accessible by all and searchable via Google and if that isn't the case, companies should strongly consider reviewing their strategy. However, I understand there are sometimes good reasons why that can't be possible (subscriptions or internal content). There are solutions, which may not be optimal but at least they help ensure you continue providing your customers access to helpful content. Here are a few we have used:
We're still awaiting a true SSO implementation to avoid having to use all of these work arounds and to provide a better user experience but at least for the time being #3 works well enough for us.
I hope this helps!
I thought I'd drop in some info on My experience with SSO, we actually still have it enabled and managed to workaround a few issues that are presented.
A big one was the user signing in elsewhere on our digital estate and navigating to the community, we had to implement a bounce page with our SSO team, the purpose of the bounce page is simply to check if a valid SSO session exists, if it does drop the Lithium cookie and return the user to the page they were trying to access on the community, if no valid SSO session is found we just push the user on to the community without dropping any cookies. This bounce page is hit on the first visit in a user session. Users don't notice anything as typically a bounce takes a fraction of a second in the browser.
We have a subset of our customers who take a particular product and for those users we grant access to a private area of the community however we've automated this process at sign-in by performing a call to check the users products and if certain products are found we pass those products through the lithium SSO cookie which tells the community to grant the user those roles for permissions purposes, equally if the user doesn't have certain products we tell the cookie to pass the option to remove the role from the user if it exists in their profile.
Working with SSO, multiple products and user permissions is possible, it just requires a little work. The biggest benefit we've seen is being able to modify the lithium SSO cookie to add/remove roles from users based on their SSO profile and this is a standard function covered in the SSO documentation that just requires a small amount of dev to set up.
You mention that users need to be on a desktop to see certain content?
If you could give examples at a high level of the different user journeys and where the pain points occur it would help us explore potential options.
SSO when set up properly can actually save a lot of admin work and pain while giving you greater insight into customer behaviour.
It appears the (now) old thread fell through the cracks, so I do apologize for that going unanswered and will work with our community team to ensure we do better at capturing and responding to all topics that go unanswered. While I could certainly see this being a "strategy" discussion, it's also a Support item, for sure. We utilize the escalation feature on the support section of the community so if a thread goes unanswered for 4 hours, the feature emails support and creates a case on your behalf. All of that said, I'll see how the strategy section is configured so content posted there gets similar treatment or at least emails a designated contact to follow up and take action.
Back on topic - I see case 00143330 was marked as resolved back on 6/19 and would love to know if the information provided there resolved your issue or not. For the sake of the community and spreading information in the event this topic pops up in someones search results, I can drop some information here as well.
This is actually a little different in that most customers go from non-SSO -> SSO rather than the other way around. When moving from an SSO system to the basic Lithium authentication system (non-SSO), the following would occur:
Curious, are you looking to do this for a short period or time or indefinitely?
P.S. Thanks @JulieHamel for the assist!