Getting rid of SSO but need something else

[ASiedsma]

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:

1. If I send a client a community link, that client must not only be logged into our product, but also must have already logged into the Community in order to access the link immediately (so it adds hassle on the client side) 
2. We have several different instances of the product, so if I"m sending someone on our NOVA servers a link, it MUST be from someone who has a NOVA SSO token, or else that person can't access the link even though it's the same Community(so it adds hassle on the employee side)
3. We have a few products that require you to be on your desktop. If someone sends an email with a link to the TKB and that person isn't at their desk top, they can't access it because they must go through their particular product.

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? 

[dianag64]

A little over a year ago, we posted a question in Strategy but never received a response ...

https://community.lithium.com/t5/Strategy/Getting-rid-of-SSO-but-need-something-else/m-p/220600

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!

[JulieHamel]

Hi @dianag64,

I've sent out the bat signal, so hopefully someone from Lithium will chime in soon. I will also go and provide my 2 cents.

Cheers,

[dianag64]

Thank you! Appreciate it!

Diana

[JulieHamel]

Hi @ASiedsma, I'm sorry it took so long for someone to respond to your question! @dianag64 pointed us here, so hopefully you can now start getting some answers.

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:

1. Account owners email lists of users needing access to content as part of the onboarding process.
2. Customers have to email the team to request access. The expectation is set that access is not granted automatically and can take a few hours to be processed.
3. We now use Alteryx, CRM data and the community API to automate the process. We run a workflow everyday that matches CRM user data to our community database, identifies the correct role based on the account type, then applies those roles automatically via the Community API. For the most part users are all set before they even decide to visit the community for support.

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!

[RobertT]

Hi @ASiedsma,

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.

[KrisS]

Hi @dianag64

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:

• SSO users would not be able to login to the community
• Any account created while SSO was disabled would be a non-SSO account and unable to login once SSO was turned back on
• Non-SSO accounts can be reconciled / converted into SSO accounts, but not the opposite way around

Curious, are you looking to do this for a short period or time or indefinitely?

P.S. Thanks @JulieHamel for the assist!