I can't find any straight forward/foolproof way to do this. From my understanding of your use case, given a windows user and the specific PI tag, you will want to determine if the user has read access to the PI tag. Some things to keep in mind:
- While security for AF objects is mapped directly to Windows users (for AF 2.6), security for the PI Data Archive can rely on Windows mappings or PI Trust. Do you intend to check for such security with only what windows mappings allow?
- Windows mappings in PI Data Archive also apply to local/domain groups that the user belong to. Will such information be provided to determine the access level?
- If you do implement such security checks, the responsibility of maintaining security lies at the client. If the security model for the servers change in the future, the client will need to be modified accordingly.
- If the user will be performing operations on many tags, you will have to implement the security check before every operation. This might have a performance impact.
Without logging in as the user, we might have to manually check for the PI mappings list, determine the PIIdentity/PIUser and check for the point and data security for the PI tag. Perhaps other community members have alternative ideas.
We'd have a system-wide option to either use Windows Security based on each user using the system OR use a single login/trust/etc. in IIS, but would not mix them. We're currently using the latter scenario in our products. Several customers have requested we integrate Windows Security, however. With kerberos/double-hop issue to properly use impersonation, it's a difficult situation in large corporate environments. Is there another way to do impersonation that mitigates the double hop?
Has anyone else run into this request. Any workarounds or ways to pass user information and get credentials?
Without impersonation there probably isn't an elegant solution. Double hop isn't such a big hump to get over, you usually just have to make the right requests to the client's security team, but I am sure you know that already.
Using a PI Trust from a Web (multi-user) environment is actually quite a security risk. The PI Identity associated with your PI Trust will need to have access to all possibilities of user permissions, writes as well as reads, if you surface that type of functionality in your application. Imagine you serve User A and User B each with distinct permissions to different PI Points, but of course the web application has access to all PI Points. With a simple request from User B to write to User A's PI Points the request would typically be satisfied (the PI Data Archive performs the Data Security ACL check as one of the first parts of an RPC) - the PI Web API used to suffer with this issue when buffering via PIBufss.
Anyway, with regards to your request...the simplest method would be as Daphne outlined; you need to parse the PI Mappings from the PI Data Archive, traverse the User's Group Membership from AD, match & find the PI Identities then you can check the PI Point Data Security ACL and Point Security ACL. Note, this is more or less what happens when impersonating the user. Of course you should cache the security lookup for the duration of web application to avoid re-parsing the PI Mappings for a particular user - you may run the risk of not picking up new/edits to the PI Mappings, which PI Coresight currently suffers with.