Authentication in windows systems is provided by pluggable security modules supporting the Security Support Provider Interface (SSPI). In most installations the provider is typically Kerberos but Microsoft offers others including NTLM and Digest SSP. These providers handle the details of providing a secure authentication including challenge/response, certificates, and key encryption to avoid password gathering and man-in-the-middle attacks. Once a user has successfully authenticated on his Windows system (usually a domain), a security token can be obtained passed and validated by server applications.
Starting with PI version 3.4.380, and PI-SDK 1.3.6, it is possible for the server to safely and reliably determine a client’s authenticated windows user and use the relationships already established in the Windows user database as mapping points into PI security. As described above, PI Server 3.4.380 and beyond assign access rights based on a new PI principal type, the PI Identity. Any Windows principal (this could be a single user or a group, from a domain or even a workstation) can now be mapped to a particular PI Identity. An authenticated domain user typically belongs to several Windows groups. If the single user and each of the Windows groups he belongs to are mapped to a PI Identities, the authenticated Windows user ends up automatically associated with several different PI Identities each of which can participate in access control lists for different secured objects in PI.
The end result is that instead of building PI Users and PIGroups and establishing another parallel security system (additional passwords to remember, control, and enforce), authentication is left up to Windows. Grouping of users is done in the native security provider’s interface, typically Active Directory and those groups are mapped to appropriate PI objects with appropriate security levels. New employees are simply added to Active Directory groups, departing one’s removed and the PI mappings remain constant. This fits well into a role based management system while still allowing distinct users to be handled individually.
Configuration and detailed explanation of Windows Integrated Authentication in PI 3.4.380 and beyond is available in the server documentation. The basic steps are creating a set of useful PI Identities (think of roles); assigning access rights for those Identities to the various PI objects and databases; and mapping Windows principals to PIIdentities (basically mapping the PI roles to the Windows groups and users).
SSPI then becomes another method of implicit authentication. With PI-SDK 1.3.6, as described above under “Trust Connections” the user or an application can decide whether or not SSPI is to be used when attempting to connect implicitly and whether it should be tried first or only after some other method has been tried. A hidden advantage of this new feature to specify the methods and order of implicit authentication is that with PI-SDK 1.3.6 multiple authentication methods can be specified in a single call to the server rather than the SDK going through a succession of connection attempts. In some cases this will reduce the number of round trips required to establish connectivity and provide a quicker connection experience.