@Dave: The recommended approach is to use a Windows local or domain account mapped to a PI Identity. I suggest you download the security guide here.
Regarding how you should design your application, you should only invoke the Server.Open method if you use PI SDK or PIServer.Connect and PISystem.Connect to connect to a PI Data Archive of PI AF Server respectively if you use AF SDK. Connection to a PI Data Archive will utilize the parameters defined in the authentication procedure section of the connection options for a computer with PI SDK/AF SDK installed. By default, the Windows authentication will be tried first and then the PI Trust.
The document should give you many details on the how and why.
Thanks - that document is very comprehensive. But from what I gather:
- It will be up to my customer to set up PI Identities mapped to AD groups, and all connections I make to either AF Server or directly to PI Server, are validated through these identities.
- Because of this, I do not need to be aware of what the customer's identities are. In fact I do not need to program in any usernames or passwords, I simply connect, and all will be well if they have configured the identities properly.
- There are alternative approaches for those not part of an AD, so the above still holds true.
- I also have a service that connects to AF/PI, in this case a PI Trust should be defined (again by the user) mapping my application to the AF and PI Server (Is that true for AF too?)
OSIsoft's recommendation is to use Windows based security (aka AD) rather than trusts or the PI authentication. In our environment we use only Windows AD for all user access and trusts on some of the interfaces (this is largely historical and we are changing).
It is important to remember how AF Data References (DR) work. The DR's are run on the client computer not the AF server. This means that the client is establishing the connection and therefore authenticating. It typically authenticates with the current user context. However, the AF SDK does allow the programmer to pass another network credential.
Where this gets interesting (or painful) is when you are writing a client/server style application (this will also apply to a web application). This scenario the AF client is your applications server, you typically don't pass the AF objects to the client. If the user, the application server, AF server and PI server are all on the same domain then everything works nicely. If however you users are on a different domain to the PI system and your application server then life starts getting interesting because you will have the dreaded double hop security problem; assuming that the connections are being impersonated. There are a number of ways to handle this:
- Setup trusts between domains and configure the SPNs
- Have the service authenticate to AF with sufficient permissions and handle the security within the application (this is probably the most common).
- The AF SDK does have methods to check the permissions of a user. So you could have the service authenticate and then use these methods to check whether the user has the necessary permissions. I'm in two mind about whether this option is a good one.
I also have a service that connects to AF/PI, in this case a PI Trust should be defined (again by the user) mapping my application to the AF and PI Server (Is that true for AF too?)
I would personally strong recommend against setting up a trust between you app and the PI Server. I would recommend my option two, run the service under a service account with has sufficient permissions (least privileged - i.e the lowest possible permissions to do the job) to PI. Regarding AF. AF doesn't have the concept of a trust (it doesn't use the PI Authentication Module). AF is all windows security. You can sort of emulate a trust by adding the server object to the permission on AF. But again this isn't recommended.
Last comment. I would recommend that you read the PI Coresight or PI Web Services documentation regarding their security setup, even though you aren't using these apps. This will give you a good insight into how the security should work.