Kevin mentioned a possible approach in his first reply to this post, I would explore that for getting Kerberos to work. Otherwise, I unfortunately don't know much about getting Kerberos to work in Ignition.
I would definitely recommend getting something basic to work outside of Ignition first so that you can separate any issues with authenticating to PI Web API from issues getting Kerberos to work in Ignition. PI Web API config is a pain to get correct.
Thanks Cody. One of the main issues I am facing in testing Kevin's approach is that I am unable to get the security files required for the AD admin. Not sure how to setup the credentials there. It can become a much easier task when there is a known tested procedure to successfully implement which is recommended by many. I am quite amazed that such a mechanic thing does not have a straight-forward SOP.
I was able to get "Basic" to work without issues. The issue is how to make it work in Ignition without hardcoded credentials of any sort as this is unaccepted in any business.
Kerberos in Ignition
I reached out to our Sales Engineering team, and here is what they suggested:
We don't have a working example of this and it is not likely a very simple concept to implement like that. More than likely some java libraries will need to be used in order to authenticate with Kerberos. Here's a project that I have found that might be useful as a starting point, but would require either wrapping this in a module or rewriting it in a way to work within jython.
Good luck, and if you get this to work, please do share with the rest of us!
I was able to get "Basic" to work without issues. The issue is how to make it work in Ignition without hardcoded credentials of any sort as this is unaccepted in any business.
If it helps, there are a few topics on the forum related to secrets management, they can help give you some ideas on how to keep hardcoded credentials out of your Ignition scripts (if you can tolerate BASIC auth):
Newer versions of PI Web API support OIDC, which might be more doable?
@h.sumrain I have another idea, but it has not been thoroughly thought out-- You can probably configure a forward proxy that abstracts the authentication away from Ignition entirely. This should be possible, at least with BASIC auth. Ignition would send requests via the proxy without any authentication information (or maybe you have some other way to authenticate against the proxy), then the proxy can inject the BASIC auth headers before passing to PI Web API.
If you don't want to authenticate against the proxy, you'll probably want to configure the proxy local to Ignition, and only accept connections from localhost. I'm not sure if its possible to configure a proxy to do something similar with Kerberos authentication.
Many thanks Cody. That sounds very creative. I just wonder why does it feel so hard to make Ignition work with Kerberos when it is native to Windows? Active Directory has been figured out long time ago most likely because it is native to Windows as well. Why would this be different or more difficult?
Again, this is a mechanical thing and it would be great if Inductive figures/creates a solution for everyone.
Java comes with LDAP support via JNDI. It doesn't come with Kerberos support.
Demand for Kerberos from customers has been nearly non-existent, and we're not particularly Windows focused unless needed.
Thanks Kevin. One of the unique capabilities in Ignition is its power of mixing between the powers of Java and Python under Jython, getting super powers from both. Isn't there a creative way to get Kerebros to work? May you please look at my suggested approach and at least share a theoretical evaluation of it?
Inductive might not be Windows focused but it seems that many of the users are. When I have the choice, I usually favor linux-based servers but the common modern trend of using VMs helped shift the decision making on this matter to other departments with different priorities and requirements.
The very first reply you got in this thread was a lead on a creative way to get it to work. See Rest API Calls with Kerebros Encryption - #2 by Kevin.Herron
I don't have a local Windows environment nor a Kerberos environment set up to even poke at this with, and I don't really know what any of the ChatGPT/LLM-generated approach you pasted in here is about.
I will try to poke around with the details in the link you shared. I agree with you on the LLM-generated approach but I came across it on a controls forum somewhere.
You might try reaching out to Sales Engineering... they may be able to help you out. If nothing else that kind of registers your interest in Kerberos via an official channel.