15 Replies Latest reply on Feb 19, 2014 12:32 AM by Bryan Owen

    No error from InsertPIData (PI Web Services)

    Rhys Kirk

      I have WIS and Kerberos delegation used throughout.

       

      If I send some data to a single PI tag (pi:\\.....) that I know I do not have write access to then I was expecting a -10401 error back (or similar error), but I don't get anything back - no ErrDesc and no TimedValues, which means the call was successful. Obviously the value isn't updated for the PI tag so why is PI WS telling fibs?

       

       

        • Re: No error from InsertPIData (PI Web Services)
          mhamel

          @Rhys: Definitely, this should not happen. Could you try a similar test but use a tag that doesn't exist? You should get as response a TimeSeries object containing the wrong tag in it and the description of the error.

           

          Do you get any results? This would help us to determine if it is related to security or just PIWS not returning when it should.

            • Re: No error from InsertPIData (PI Web Services)
              Bhess

              Rhys,

               

              Just ran a quick test against our latest version with the same configuration using WCFstorm, and got an error (-10401) as expected.

               

              3377.Test.png

               

              Any more details on your configuration that you could share?

               

              Thanks,

               

              Brad

                • Re: No error from InsertPIData (PI Web Services)
                  Rhys Kirk

                  I had a tag with read-write permission for the identity my account maps to, works fine.

                   

                  I had a 2nd tag where I don't have read permission, using getsnapshotdata I get an error. Using InsertPidata gave no error.

                   

                  I had a 3rd tag where I had no write permission, using insertpidata gave no error.

                   

                  I have PIBufss running on the PI WS server.

                   

                  I did a simple test in Visual Studio adding a service reference and then called insertpidata.

                    • Re: No error from InsertPIData (PI Web Services)
                      Rhys Kirk

                      For arguments sake I used WCFStorm, and no error returned.

                       

                      Now if I stop/disable pibufss on the PI WS server then I do get an error back that PIBufss couldn't be started..."-2147209216: Pibufss service is not running. Unable to buffer. PI buffer subsystem should be running but isn't. Start attempt failed.".

                       

                      With pibufss running the event is passed to pibufss and then sent to the PI Collective, where it is rejected because PIBufss doesn't have write privileges either. However, the value shouldn't even be passed to PIBufss because no Identity (from the process id or user id) anywhere in the chain has permissions to write to the PI Point.

                       

                      Is there logic within PI WS that if it is a PI Collective that there is a requirement for a buffering mechanism, and is that somehow bypassing the PI Point write permission check?

                        • Re: No error from InsertPIData (PI Web Services)
                          Bhess

                          Aha-- you're writing to a collective.  This behavior actually comes from the PI SDK, which sends the data to PIbuf without checking security.  Since the write permission to a PI Point could ultimately come from a Trust, and not just a Windows Identity, checking the security isn't entirely straightforward.  I can connect you with one of our PI SDK mavens if you'd like further intel.

                           

                          Best,

                           

                          Brad

                            • Re: No error from InsertPIData (PI Web Services)
                              Rhys Kirk

                              Thanks Brad, and yes please.

                               

                              I don't believe this behaviour is acceptable, and I'm not often one to complain. Security should never be bypassed IMO. Would love to know more detail on this.

                                • Re: No error from InsertPIData (PI Web Services)
                                  Bhess

                                  Sorry if my answer led you to believe that security isn't being checked /at all/.  Indeed it is, just that the check is not happening within the SDK, and the error isn't making it back to you cleanly.  I'll confer with the SDK folks and get you that documentation.

                                   

                                  Brad

                                    • Re: No error from InsertPIData (PI Web Services)
                                      Bhess

                                      And so, after getting educated with the PI SDK team, what we find is that the PI SDK /never/ checks security client-side before sending a write to the PI server.  This is true for a number of reasons-- e.g. the PI SDK may not be on the same domain as the PI server, or not on a domain at all, or the SDK's user account may not have permissions to enumerate accounts on the Domain Controller, or perhaps may not even know how how his IP address or hostname will appear on the other side of the network, for the sake of evaluating a trust.  

                                       

                                      Finally, industry best practices demand that any security check be done on the server side, regardless of whether security has already been checked on the client side, to prevent a variety of spoofing attacks.

                                       

                                      So in terms of how that ends up from a user perspective:

                                       

                                      - In the case where PI SDK is writing synchronously to the PI Server (i.e., not through PIbuf), the PI SDK begins a write RPC to the PI Server.  The PI Server evaluates the request, and if the PI Server determines that the caller does not have permissions to write, that error is returned in the RPC response.  The PI SDK can send that error cleanly up the stack through PI Web Services back to the calling user.

                                       

                                      - In the case where PI SDK is writing asynchronously to the PI Server through PIbuf, the PI SDK forwards the request to PIbuf, and then returns a response back to the user.  The response is simply an indication as to whether or not the write was accepted by PIbuf.  Just like the SDK, PIbuf doesn't -- nay can't-- have all the logic to evaluate the write request.  So if there is a security error when PIbuf gets around to writing the value to the PI Server, the only place it'll appear is in the PI message log.

                                       

                                      According to the former Dev Lead of the SDK, there's been a long standing request to implement some kind of error queue in the SDK, so that PIbuf can notify the SDK when there's a value that's not accepted by the PI Server.  From a Web Services perspective, even if this functionality were added to PIbuf and the PI SDK, this would lead to a pretty complicated invocation pattern.

                                       

                                      Anyhow, I'm glad you had this question.  This is a really good case for us to keep in mind as we work on our REST APIs.  Whereas a synchronous write might return a 200 OK, a buffered write had probably ought to return a 202 Accepted, indicating there's post processing that needs to occur before the value could potentially show up.

                                       

                                      Hope this explains, if not satisfies.

                                       

                                      Best,

                                       

                                      Brad

                                        • Re: No error from InsertPIData (PI Web Services)
                                          Rhys Kirk

                                          Okay thanks for following up Brad.

                                           

                                          It certainly explains what is happening even if I don't like it We're peanalised as a client for implementing a technology that facilitates server side data consistency, i.e. if you buffer you're in the dark, or if you have a PI Collective that you fan to you're in the dark. No doubt the AF SDK with PIBufss has the same issues for the REST APIs.

                                           

                                          Is there an enhancement request with AF SDK / PIBufss 4.3+ to address this?

                                            • Re: No error from InsertPIData (PI Web Services)
                                              Rhys Kirk

                                              And...I continue to rant...in PI Web Services if the privileges of PIBufss is > than the impersonated client then I can update any PI Point that PIBufss has write privileges to even if I don't explicitly have those write privileges as a user, even though I've implemented complete WIS with no PI Trusts. Does that not worry anybody else?

                                                • Re: No error from InsertPIData (PI Web Services)
                                                  Bhess

                                                  In terms of the enhancement request to AF SDK/PIBuf for returning an error state --  

                                                   

                                                  The request is certainly there.  For background, the purpose of PIbuf is to provide a 'fire and forget' mechanism for other components, in situations where you might not be able to talk to one or more PI Servers (e.g. intermittent network connectivity, server downtime, etc).  For the reasons stated previously, it's not practical to check write security on the client side, either in PI SDK or in PIbuf.  The combination of these two facts suggests that there isn't really a more elegant solution to this problem than an error queue within PIbuf that gets filled as the writes are attempted, and that a client could periodically poll.  If PIbuf were to implement that functionality, then I'm sure that the AF SDK would happily provide a wrapper, perhaps in something akin to Data Pipe format.

                                                   

                                                  In terms of the fact that PIbuf doesn't impersonate/ignores the caller's security/writes using its process account and that's what shows up in the audit trail--

                                                   

                                                  I would expect to see a resolution to this issue sooner, since it's also a common customer request, but more pressing from a security perspective.  I can tell you for sure that it's not scheduled into PIbuf's upcoming release, which is nearing completion.  But that there is lots of talk within OSI about how we can do a better job with identity, especially as the world is moving to claims-based solutions, and I would expect for PIbuf to be included in that re-imagining.

                                                    • Re: No error from InsertPIData (PI Web Services)
                                                      Rhys Kirk

                                                      Could you answer one more thing for me. PI SDK writes are evaluated on each RPC  on the PI Server server side. Doesn't AF SDK do the opposite; it pulls AF security configuration client side and then evaluates if the calling identity has permission (specifically WriteData) before passing to PIBufss (from 2.6 onwards)? True or False?

                                                        • Re: No error from InsertPIData (PI Web Services)
                                                          Bhess

                                                          Assuming buffering in all the cases here:

                                                           

                                                          When writing to an AF Attribute, the AF SDK calls the AF server, and asks for the identity's effective permissions on the containing AFBaseElement before attempting the write.  If the WriteData permission is missing, then the write will not be passed to bufss.

                                                           

                                                          If, however, the AF Attribute is backed by a PI Point Data Reference, and the client has WriteData in AF, but not on the PI Point, then he's in the same boat as we discussed above.  Only the AF permission is checked, and then the call is passed to bufss.  The bufss identity is used for the write.

                                                           

                                                          Using a PIPoint from the OSIsoft.AF.PI namespace also yields the same behavior as the PI SDK in this case.

                                                            • Re: No error from InsertPIData (PI Web Services)
                                                              Rhys Kirk
                                                              You know what I'm hinting at here AF SDK is able to establish permission from the Element ACL before the attempted write. When a PI Point is retrieved (PI SDK or AF SDK) you could expect that the effective permissions from the Point's Data Security ACL, based on the PI Identity for the connection, is evaluated client side before attempting the write - after all you're not concerned with Domains/Accounts etc it is just am I associated with a PI Identity with write permission. I know this isn't the case nor in the plans from what I can tell, but it seems you can load up the PI Server for RPCs you know too well won't succeed. I wonder what the overhead is for a PI Server evaluating each RPC? I'm not saying that check shouldn't occur server side for each RPC but what if you significantly reduce attempts, does that free up PI Server resources for more scalability? Think of this in the same manner as a PI Interface providing Exception reporting where the PI Interface retrieves Exception settings, and then evaluates client/interface side if the significant event should be sent to the PI Server...the same pattern could apply to data writes. I've gone a little off topic here but you know right now I have serious doubts over PI WS with Impersonation in a buffered HA environment. The same concern is going to come with OData/Web API.
                                                                • Re: No error from InsertPIData (PI Web Services)
                                                                  Bryan Owen

                                                                  ...right now I have serious doubts over PI WS with Impersonation in a buffered HA environment. The same concern is going to come with OData/Web API.

                                                                   

                                                                  Your concerns are well founded and are captured at a high level this MSDN article about trusted subsystem design.

                                                                   

                                                                  msdn.microsoft.com/.../aa905320.aspx

                                                                   

                                                                  There are pros and cons to either approach.

                                                                   

                                                                  PI Web Services impersonation/delegation or trusted subsystem model manifests in entitlements for userID or processID respectively.

                                                                   

                                                                  Buffering reduces the identity options used for write methods to a single service identity per machine.  For instance, users authenticated to the web service and granted a database role with write access to a common subset of points.

                                                                   

                                                                  Of course it would be good to offer more flexibility. To echo Brad's comment, the design will benefit from some re-imagining for claims based security as well as closing the gap on security design goals.

                                                                   

                                                                  -Bryan