Don’t Make These Mistakes if You Want Your SSO Project to Succeed

Michael Knight, President & CTO, Encore Technology Group

If providing easy, one-stop access to all applications from any device or location using a single password is your goal, a full-featured single sign-on (SSO) portal that includes a comprehensive, integrated identity access management solution may be just the answer you’ve been seeking. Though simple in concept, getting SSO right can be tricky and the potential for costly missteps is high. So, before you attempt to rollout a SSO initiative of any size or scale, carefully consider the following advice from Encore’s President and CTO, Michael Knight, to ensure the success of your SSO investment.

Don’t start until you know what applications you have. Taking inventory of what your users currently have access to should heavily shape your goals for the project, ensuring they’re getting the all resources they need. “If you haven’t thought through, ‘What do my people actually have access to and what do they use each day?’” says Michael “It makes your deployment that much more difficult. If you haven’t talked to every key stakeholder, each school, each C&I person, media specialist, the individuals delivering the technology at each location; talked to your engineers, IT director, CIO or CISO risk manager if you have one, your supervisors and assistant supervisors—you’re setting yourself up to fail from the beginning.” Once you’ve done internal assessment, you’ll have a better understanding of what your users expect out of your SSO deployment.

 

Don’t approach implementation without a plan. “If you haven’t discussed a project summary where you reviewed what your objectives are or what you’re trying to achieve, then no platform will be able to provide the desired outcome.” Michael advises to create a project plan and charter designating when to roll out specific applications, and which instances require more sensitive information. This helps schedule the creation of security groups and determines the applications or administrative rights those groups need. This exercise also highlights applications that need additional preparation before they can be added to an SSO environment. Tools such as Slack require you to buy an enterprise-level plan in order to integrate with SAML, which can easily put you over-budget if those costs are not known from the beginning.

Don’t forget to include users that fall outside of the norm, such as consultants, vendors, temporary employees, parents, volunteers, etc. Michael asks, “Identity data drives what users are going to have access to, but where are you pulling user identities from? Maybe to populate staff accounts, you used your human resources management system. Well, are all your bus drivers in there, or not? Are your volunteers in there? Possibly not. Are your contractors? Generally not. Well, then how do you know what resources those individuals are supposed to have? You have to think, ‘Who exists in my district, role-wise? Do I want to give parents access to things?” Providing credentials to individuals on the periphery of your organization is a great use of your SSO platform, encourages participation in the larger organizational community.

Don’t attempt provisioning without first verifying the accuracy of identity directory information. Not taking the time to clean up muddled identity information – authoritative source data – can greatly slow down an SSO implementation, or even halt it entirely. Provisioning relies on sound identity information to create the organizational groups and roles your users need to be a part of to gain access to their applications, links, and files. “SSO doesn’t start at the application, it initiates from a user’s identity. Without reliable data, your SSO platform is a house that has no foundation or solid infrastructure. One gust of wind blows or you close the door a little too hard, and then there’s nothing there. That’s what SSO is going to give you without being able to relate back to straightforward identity data.”

Don’t assign users more than they need. “Once you know what you want to allow users to access, you then have to think through the types of platforms you’ll need to send identity data to. And even after sending it, you’re still responsible for it. It’s your data that you’re choosing to provide to a third party. Security contracts don’t matter when a breach occurs; you’re still liable” Michael cautions. “Can you tell your forensic breach investigators, your school board, and your community at large, ‘“I know exactly what data I have to give to these providers and I’ve only given them the bare minimum least privilege required’?” Though it may seem less complicated to provide everyone in a particular role with any application they could possibly need, this undermines your data security. Create organizational groups to delineate the exact tools that will populate users’ SSO portals.

Avoiding the mistakes above can translate into greater return on investment on your SSO platform and increase the overall productivity of your organization. For more information on how to make the most of your SSO deployment, feel free to reach out to us at enboardinfo@encoretg.com.

Leave a Comment