Single Sign-on / SSO / SAML

[FluidNets-DamianS]

I am appreciative of the sign-on with Microsoft. However as we are planning to integrate our new KB/documentation repository I am faced with a new dilemma. I can have MS users auth via SSO but I have no way to authenticate users who setup a DDportal password.

Best solution is to simply use an external SSO provider OneLogin, Okta, miniOrange and have all auth provided from there unless DD can auth users from other systems.

[Nness]

One of down side for SSO is Vulnerability. It is critical to make sure SSO provider themselves is secure.

For now, SSO provider is on low priority. First we already have so many way to login into portal, it even include email token(Passwordless). On the other hand, we do need time to verify SSO provider, to see how reliable they are.

MSFT, Google, Facebook etc, those big company have been constantly bombard with security attack, while for SSO provider like lastpass, 1password are similar, but OneLogin, Okta and miniOrange, I am not certain.

Good SSO provider should have asked security research to perform test against their system. Here is one of Sample report. How many of those platform did those test? This question is for any platform that stores critical user data. Include password.

[FluidNets-DamianS]

RavenDB is an odd comparison since they are not an authentication provider. Regardless any legit provider will perform security penetration tests against their platforms as they are legally required to perform all due diligence for their services. https://www.okta.com/sites/default/files/Okta%20Technical%20Security%20Whitepaper.pdf

Aside from that you are already trusting Microsoft in similar fashion. I think the passwords authentication provided in DD is one of the most insecure protocols ever due to the fact that emails systems are the most compromised systems. In addition to end-users simply forwarding emails to other people. Hence why we paid for a platform for over a year and could not deploy do there not being any acceptable authentication for our end-users.

Providing SAML or OAUTH and allowing me to choose what I will authenticate against is a widely accepted standard among software developers. It is not like DD contains my deepest darkets secrets. Our ticketing platform is probably the system I am least worried about.

[Nness]

I will look into OneLogin and Okta see how we want to implement it in the future.

[Aycorn]

Similar Request: Service Ticket #22294 - Okta integration

[DevanMorrison]

Advised by support to add our comments here. We're requesting the ability to login via a Google SSO/SAML. Many school districts in our region (and even nationally) use G Suite for Education (or Google Workspace as now known). This encompasses their entire operation from a mail client, user permissions, device group policy, etc. Their life lives at school live in that ecosystem entirely. Think of it as a similar setup to O365, just on a Google ecosystem.

With a Google SSO/SAML we could authenticate against their account for an even simpler passwordless login in a similar manner to other services these districts use daily. Furthermore, it pushes for an increase in quality of life. For example, right now we actually had to revert back to the Connectwise survey as the password & magic token were a bit confusing to school district staff. The magic token is akin to MFA, which many staff members do not use/do not like -- even though it's best practice security. When switching from a CSAT link that went straight from the link to the survey, we had quite a decent selection of results. When we flipped to the DD campaign our survey result uptake was less than 10% of what was accrued normally before (even though our volume is consistent). When we asked about seeing the difference, many staff told us the portal wasn't easy to use/navigate. This would further explain why us pushing the portal has been a slower and not as accepted platform versus email connector tickets.

A Google SSO/SAML would solve numerous issues for us, notably an end-user QoL issue.

[iskolares]

related request #26401