Hi team,
I need to send data using REST API POST requests to a system that has kerebros encryption while the Ignition side use Active Directory within a domain. What do I need to do to enable it in Ignition while continue with AD for user access?
Or in another way, how can I send POST requests that are encrypted with kerebros through an Ignition gateway that is accessed with AD in a corporate domain? Are these two interconnected or mutually exclusive?
Ignition has no support for this kind of authentication in its HTTP client.
You might be able to get something working using the [apache httpclient library(Apache HttpComponents – HttpClient Overview), which is available on the class path in Ignition.
In this post the OP manages to get it working using an NTCredentials object, perhaps that could be a starting place for Kerberos, which it seems apache httpclient does support: KerberosCredentials (Apache HttpClient 4.5.14 API)
If that is the case, how can any one successfully connect Ignition to PI using the encrypted Web API method?
PI is one of the biggest historian players. IA's documentation in successfully establishing bidirectional communications to big market players is a bit behind to be honest. These low level mechanics need better be streamlined and figured out rather than every expert spends significant efforts individually...
Maybe nobody is? Maybe via a different authentication method?
Why aren't you connecting PI to Ignition using one of its OPC UA connectors/adapters instead?
Because nobody is recommending it as a stable scalable approach? If there are resources saying otherwise, they shall be very helpful.
Using this method as it seems to be the only one that is common between Ignition and PI.
Here is PI encryption options:
• Kerberos
• Basic (clear text username and password)
• Anonymous (no authentication)
• Bearer Token
While Ignition's options are found here.
How would you suggest making it work? Web API in PI is meant to be superior to other legacy options so it is great if Inductive helps make this work?
Use Basic Auth and make sure that you're communicating with OSI PI over HTTPS so it's not actually in clear text.
You're conflating encryption and authentication. They're different concerns.
Help me out here please.
When PI has Kerberos enabled, an API GET call returns access error denied. When it is turned off, the same call returns a good value. It sounds like I am confusing the two but it seems that there is a hidden issue in here.
For "Basic", what shall be in the API to make it work? I tried something like this but without success:
system.net.httpClient(username="XX", password="YY")
Kindly advise.
client = system.net.httpClient(username="XX", password="YY")
This is indeed how you would create a client that was configured to use basic auth with the provided username and password.
I have no idea what you have to do in OSI PI to enable Basic Auth or configure the authentication sources. I only know that's possible because you told me it was possible in an earlier post.
Is PI configured to accept web service calls with Basic Auth?
I've never used PI, I can't really help you out with this much. Hopefully somebody else with some experience using their web API comes along...
Are you trying to send data to PI or get data out of PI? If the former, you're probably better off using an OPC UA Connector or Adapter. You mention scalable, what sort of scale are you looking for? I doubt a custom solution with Web API will be more scalable, although it's probably possible with a deep understanding of how PI Web API leverages AFSDK.
To enable BASIC auth in PI, you have to add it to the AuthenticationMethods attribute in the AF database. You'll also have to make sure you've got the CSRF headers or turn off CSRF defense in PI Web API.
When PI has Kerberos enabled, an API GET call returns access error denied. When it is turned off, the same call returns a good value. It sounds like I am confusing the two but it seems that there is a hidden issue in here.
Can you show exact requests/responses? It's possible that the user you are authenticating with simply does not have access to whatever resource in PI you are trying to access.
Thanks Kevin. Just a couple of follow up points:
1- Which username and password to be used since Active Directory is used for authentication? Or is it just a dedicated account that is configured to access PI?
2- Wouldn't having the username and password as text create risk?
The four authentication methods I mentioned are taken from PI's documentation. The PI gateways has the web api enabled and the fact that an anonymous read does the trick confirms it. It is more of a security issue.
Thank you so much for your response. For now I'm trying to send but I want to succeed doing both. The Web API in PI was designed to be the superior method to succeed other legacy protocols. Are we just sticking to the old solutions and stay away from modern ones because no one was able to make it work?
As for the OPC-UA, from my research, it seems to be clunky and not an ideal production solution. If a Web API request is sent for each single value, it won't be efficient for sure. However, if the values are sent in bulk, I trust that it shall be much more efficient than other methods. Just similar to grouping data in MQTT packets.
Would you mind elaborating more on this:
I do not have snapshots for the previous requests and responses but I will try again and see how it goes. Will update the thread afterwards.
I'm in the middle of doing the exact same task (Ignition to PI using Web API) so I'm very interested how this goes for you and very much look forward to seeing an update
The Web API in PI was designed to be the superior method to succeed other legacy protocols. Are we just sticking to the old solutions and stay away from modern ones because no one was able to make it work?
OPC UA is by no means a legacy protocol, and OSI/AVEVA actively maintain the connector, and they actively develop new features (albeit slowly) for the adapter. PI Web API was largely meant as a replacement for legacy PI API and as an alternative to directly using PI AFSDK. It allows PI developers to deploy lightweight/cross-platform http clients instead of depending directly on large Windows only libraries. It was not meant to replace interfaces/connectors/adapters.
If you're wanting to move data from Ignition to PI, and that data can be accessed with OPC UA, you are probably better off starting with PI Adapter for OPC UA (which will send OMF data to PI Web API). If you run into some issue, you could probably augment your solution with some custom PI Web API apps if needed, but the adapter is going to be your best starting point for getting tag data to PI. (& If you need history, consider the RDBMS adapter)
As for the OPC-UA, from my research, it seems to be clunky and not an ideal production solution.
Do you mean OPC UA in general, or specifically the AVEVA/OSI/PI Adapter or connector? If the former, I think you're simply mistaken, as OPC UA is industry standard for system interoperation. I'm pretty familiar with the AVEVA Adapter for OPC UA, I'll be the first to say it certainly has some issues, but for simple data ingress to PI, I think you should start there.
If a Web API request is sent for each single value, it won't be efficient for sure. However, if the values are sent in bulk, I trust that it shall be much more efficient than other methods. Just similar to grouping data in MQTT packets.
I don't doubt that you could be nearly as efficient as the adapter, but when performance testing the OPC UA adapter, PI Web API is the bottleneck. This is why I asked what scale you're looking for. If you're trying to push data more than the adapter can, you have too high of an expectation for PI Web API. AVEVA advertises that the adapter can do 50,000 events per second (I'm very skeptic of this number).
Would you mind elaborating more on this:
The hyperlink in that text you screenshotted is a link to the PI Web API documentation that explains the authentication methods and how to configure them within your AF database. There's a section in there about "Other Security Settings" that explains CSRF and other issues. OSI/AVEVA used to have some working examples in a few scripting languages of how to use PI Web API, I would start with getting one of those to work, then work on moving that to Ignition. This way you can isolate issues connecting to PI Web API, and work with AVEVA support to resolve them. I'm happy to help as much as I can with PI Web API, but during my time at OSIsoft and AVEVA, I always had the security settings turned off in my local dev instance, and I don't remember all the specifics to getting it configured "correctly."
Which username and password to be used since Active Directory is used for authentication? Or is it just a dedicated account that is configured to access PI?
If I remember correctly, this would be the credentials for the AD account that has access to PI. Remember there are several places where access needs to be given to this user within a PI System ( PI Data Archive, PI Asset Framework, and PI Web API each have their own authorization settings, I think)
Wouldn't having the username and password as text create risk?
Yes. If you're using HTTPS, then the password is at least encrypted, however. AVEVA recommends using Bearer authentication.
For now I'm trying to send but I want to succeed doing both.
If you can share more info about your overall use case, including deployment architecture, tag counts, event counts, etc. I can try to list a few options for you.
I worked as a developer at OSIsoft/AVEVA for around 7 years before I started at Inductive Automation last year.
Many thanks for the detailed response Cody_Morgan.
OPC-UA is a protocol that has been tested for decades and proven reliable. The point is about PI's implementation of it which is known to be glitchy.
Appreciate the thought but that might actually become more complex from a maintenance point of view. The thought is to build a standardized scalable approach without issues.
The scale is expected to be around the 50k events per second or aim for that as a benchmark. Have you done actual testing on both OPC UA and PI Web API and found that the Web API is the bottleneck? If so, were you sending every single value in a separate request or you were batching them?
It is a no-go on the basic authentication as the only security option enabled in PI is Active Directory so we need Kerberos to work in Ignition. The use case is just setting up a new Ignition gateway and have a direct connection to PI to historize data from it.
I came across this approach and I would appreciate it if someone can test it as I am unable to at the moment.
GOAL:
curl, PowerShell, or a browser)Step 1: Prerequisites
Make sure that:
Step 2: Create an SPN and Keytab
On the domain controller, open PowerShell as Administrator and run:
powershell:
setspn -A HTTP/ignition-hostname.domain.com DOMAIN\IgnitionServiceAccount
ignition-hostname.domain.com = FQDN of your Ignition serverDOMAIN\\IgnitionServiceAccount = the AD account running Ignition GatewayThen, generate a keytab file:
powershell:
ktpass -princ HTTP/ignition-hostname.domain.com@DOMAIN.COM -mapuser DOMAIN\IgnitionServiceAccount -pass YourPasswordHere -out C:\path\to\http.keytab -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1
Place http.keytab somewhere accessible by the Ignition Gateway service.
Step 3: Configure Identity Provider in Ignition
KerberosSSOSSO OnlyDOMAIN.COMyour-domain-controller.domain.comHTTP/ignition-hostname.domain.comC:\\path\\to\\http.keytab
Ensure the Ignition service has read access to the .keytab.
Step 4: Set Up Security Levels (Optional but Recommended)
Step 5: Enable Authentication for REST API Access
Check “Enable Authentication for Web Services”KerberosSSO)Step 6: Test REST API with Kerberos Ticket
-Using curl from a domain-joined machine:
bash
curl --negotiate -u : -X GET https://ignition-hostname.domain.com:8088/system/gwinfo
* `--negotiate`: Tells `curl` to use SPNEGO/Kerberos
* `-u :` → sends ticket without prompting for username
* Must be run from a user **logged in with a valid Kerberos ticket**
To confirm ticket:
bash
klist
Optional: Test via Browser or Postman
* Modern browsers (like Chrome or Edge) support SPNEGO automatically if the Ignition FQDN is in the **intranet zone**
* Postman **does not** support Kerberos/SPNEGO natively — use `curl` or a tool like **httpie** or **custom code** (e.g., Python `requests_kerberos`)
---
## đź› Troubleshooting Tips
|**Problem**|**Solution**|
| -------------- | -------------- |
|❌ `401 Unauthorized`|Check SPN, keytab, realm spelling|
|❌ `KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN`|SPN not registered or mismatch|
|❌ `KDC not reachable`|Wrong KDC hostname or firewall issue|
|❌ Ticket expired|Run `kinit` again or re-login|
|đź”’ Keytab permission error|Ensure Ignition has read access|
Would this work and enable kerberos in Ignition?I hope you aren't holding your breath waiting on this. It's not a small ask on a volunteer forum.
I'm not holding any breath my friend but I would believe finding a solution to this can be helpful to many. People shouldn't have to waste time on mechanics. These solutions are better public if found. I would Inductive would consider doing something about it.
You should have heard him talking in private about PI's web API 
OPC-UA is a protocol that has been tested for decades and proven reliable. The point is about PI's implementation of it which is known to be glitchy.
I'll grant you that the PI Adapter has had many issues and is far from perfect, but if you're only seeking to send real-time tag data, it would work fine. The only outstanding issues I can remember were related to failover and reading metadata. I would recommend you at least give it a try before going down the path of rolling your own solution.
Alternatively you could try the RDBMS adapter. It also won't do failover or read meta-data, but you may find reading from the database instead of using OPC a bit easier. (I'm biased, but I also think the RDBMS adapter is overall less buggy.)
Even if you use an adapter for data collection, you'll still have to figure out how to connect to Web API if you want to read data back out from PI. The PI Interface for RDBMS might be able to do "outputs" but they do minimal maintenance on interfaces these days.
The scale is expected to be around the 50k events per second or aim for that as a benchmark. Have you done actual testing on both OPC UA and PI Web API and found that the Web API is the bottleneck? If so, were you sending every single value in a separate request or you were batching them?
Yes, my team and I ran countless performance tests while I was there. Granted, my performance tests with PI Web API were limited to use cases with OMF data and not regular streamset write calls. You can probably get 50k events/second with OMF (no idea about the regular API), before I left I think the biggest performance issue was the OMF container create/updates.
One trick to keep in mind-- PI Web API performance somewhat scales per user. So if you do hit a bottleneck, you can try splitting the load between two connections each authenticated with their own user.
Good luck! Feel free to keep us in the loop, I'm happy to help where I can.