How are Vision Auto-Login Credentials Stored

Prior to Ignition V8.1.17 we used the Enable SSO option to launch vision projects without any authentication visible to our users. When we update we are considering switching to the Auto-Login option and have some questions.

I believe the Auto-Login option for vision projects should step around the SSO security concerns,
Is this assumption correct?

Does Auto-Login introduce any security concerns of comparable severity? (We’re fine with users being able to access these vision projects if they have access to our network but don’t want to open up arbitrary remote code execution, for example).

We are considering using accounts back-ended in an AD User Source. IT is understandably concerned about AD account credentials staying secure, even for low permission users. Once input into the project properties, how are these credentials stored?

Related to the SSO vulnerability, the technical advisory specifies that “So long as you know the username of any user with privileges to access the Designer, you can log in as that user into the Designer without having to supply their password.” What are the security implications of re-enabling SSO in ignition.conf but disabling Allow Designer SSO? (Effectively allowing SSO to vision clients but not to the designer.)

Thanks for taking the time to read through my wall of text :slight_smile:

No, you’re correct; there’s obviously a tradeoff of security vs convenience, but auto login doesn’t expose the SSO vulnerability.

They’re stored (unencrypted, unobfuscated beyond Java serialization) in the Vision login properties project resource. What you could do is switch your project to an Internal user source configured for soft failover to your actual AD user source. Thus, the auto-login credentials can be invented and only apply to Ignition/your Vision project(s), and you can still log in with your AD credentials when appropriate.

Basically, just that anyone could authenticate (as a Vision client) from anywhere as long as they know your domain and a valid username to impersonate. This is essentially the same tradeoff as autologin, but harder to control.

Thanks for getting back to me so quickly, @PGriffith.

By “harder to control” I assume you mean that anyone with Gateway Config Section access can flip Designer SSO back on. vs. ignition.conf can be accessed by a (potentially) much smaller group of people. Did I understand you correctly?

Is there any hope of a new, more secure implementation of SSO being introduced in a future version?

That, and also, with autologin everyone’s going to show up as one user in e.g. audit trails. With SSO enabled, anyone could be anyone; you lose any guarantee of ‘trust’ in authentication in the system.

Yes, it’s definitely on our radar. However, we need to do it “right”, especially with an eye toward “future-proofing” (e.g. cloud based stuff, mutual auth based on certificate sharing, etc).

1 Like

On the Security Best Practices for Your Ignition System Webinar, I asked a question about SSO and the answer I got was:

The feature as we know it today will likely never come back in its current form, and it will likely be removed altogether. But down the road [Inductive Automation] plans on investigating how they may introduce Kerberos support, which would give users a more secure Industry-standard method for achieving the same Desktop SSO experience.

Listen to the Webinar recording starting @ 31:27.

1 Like