Thank you Rhys. Yet again, good observations and insightful questions on your part. If I understand correctly, what you’re asking for some sort of “dynamic” or context-based access control. As usual, the devil lies in the details. But first, I would like to clarify a few things.
It’s best to see WIS authentication has having two phases. The first phase, in Windows (note: a domain controller isn’t mandatory), produces a Windows token with your SID(s); the second phase, in the PI Server, turns these SIDs into PI Identities. PI Identities essentially become your capabilities or “roles” (I’m using this term very loosely) alongside the Windows Principal that defines your identity.
Authorization happens later when you use these PI Identities to request access to PI Points or other data structures. The PI ACLs or security descriptors on these data structure will decide whether or not you have access. So even with PI Trusts, authorization was never IP or application-based, but rather based on the PI User or PI Group these trusts were configured against.
This means that if you can configure your applications to run with unique Windows accounts (or unique Windows group memberships) and have the corresponding PI Mappings and PI Identities, you can accomplish the same granularity of access control as PI Trusts (while relying on Windows for identity management). I agree this may be more work but fortunately, Microsoft is helping with things like Managed Service Accounts that first appeared in Windows Server 2008 R2.
Now where do we take it from there? Your suggestion of “sub-mappings” sounds interesting and potentially promising, but it might force us to essentially implement a proprietary claims-based security scheme. I’m reasonably sure we won’t take this path and instead look into industry standards. I know for a fact we’re also looking into certificate-based authentication, especially for headless applications like PI Interfaces or light-weight devices.
I’ll let our security experts add further comments if they wish to. In the meantime, rest assured that system manageability (i.e. cost of ownership) is always a primary concern for us. Please let me know if I didn't understand your needs well enough –and thanks again for pushing us forward!
Thanks for the detailed response Denis.
Context-based access control, and claims-based security are a couple of terms I would relate my original question to. I also have thoughts over "privilege leak", which I will explain some more on what I mean. Oh, I'll throw "token bloat" into the mix whilst I am at it.
What do I mean by "privilege leak"? Well consider that a user, or group of users, connect to a PI Server and based on their AD group membership map to the associated PI Identities. Now of those PI Identities mapped there is a more privileged PI Identity that has authorisation to do some stuff that the user(s) only need for 1% of their role. By using PI Mappings they carry that extra authorisation no matter what they are connecting to the PI Server for, and if you consider that they could unintentionally perform highly privileged actions against that PI Server then that to me is a leak of privileges.
This was my main reason for nesting PI Trusts (or similar concept, doesn't have to be called Trusts...how about claims ) within PI Mappings. You get the least privilege on your initial mapping to the PI Server and only as & when required you can elevate your privileges (associate additional PI Identities with your connection) by running certain applications or connecting from certain devices etc. A pseudo "User Account Control" for PI Server connections.
I realise that the recommendation is always to have a thoroughly well designed security structure and well designed PI authorisation setup but in large enterprises I fail to see such recommendations adhered to all the time. Typically it is too difficult to do so, or there are historical setups that take time to unravel and set straight. Or just a lack of solid examples on best practices for various scenarios.
The switch to WIS has also meant that SIDs associated with users has increased and depending on the granularity of AD groups for authorisation (multi-tenant PI Servers) it's increased a lot leading to token bloat. I've already seen this with CoreSight where users can't connect because they are bloated so you need to increase the http header size, which in it's own right could be a DOS security risk. So security is increased on one part and decreased on another.
Also, right now if you use a combination of PI Mappings and PI Trusts then you can end up in the situation where your PI Mappings take precedence over the PI Trusts and you don't get the required PI Identity from the PI Trust - you would if the PI Trust was nested.
Bump...never did hear any more from Bryan and co. on the viability of something like PI Mapping + nested PI Trusts.
I think that this moves away from the Roles-based security that Microsoft (and others) are focused on.
If someone has permissions to do something (because they fit a particular role), then it shouldn't matter which application they utilise to perform that action. They have permissions to do it. (which tool is best for the job is something they are expected to have the intelligence to work out.. since they have been given this role)
It would be possible to emulate the restriction that you've talked about simply by limiting the applications that people are allowed to execute. This can be done either through a particular piece of security software (something which has a whitelist of allowed applications), or even through some kind of use of Windows Firewall.. you could say that only certain applications are allowed to be used to target the PI / AF ports from within your environment. This then restricts what tools can be used to perform the particular tasks.. and who can perform the tasks can be restricted with the standard roles based security.
If you are using a custom application, then you can always use Managed Service Accounts, or Group Managed Service Accounts to perform the actual permission restricted activity. And then have this custom application reference some other authentication database as to what users are permitted to operate the application.
Just my two cents (of the Australian variety..)
Hey Bevan. Thanks for the Australian two cents. Not sure I completely agree with you. This wouldn't move away from Roles based security, that would remain, even in Claims based security you still implement role based security based on the output from the claims. It is just that the authorisation layer has more intelligence about the entity (doesn't have to be a human) that is requesting authorisation to compile the multiple claims - which is essentially what I mean by Conditional PI Mappings. Interface/Application certificates for a claims based world (mentioned by Denis above) sounds interesting and is a pseudo conditional PI mapping.
The connecting application is as important as the connecting user, because a user can belong to many roles (piadmin, pidemo, ...) so you wouldn't want them to be too privileged for non-administrative activities as that would bring around unintended behaviour when interacting with the PI System. There are lots of online conversations about how Microsoft should have native support for Activities based authorisation which is what I've always wanted to see in the PI System - you connect as least privileged then elevate depending on what you need to do. Extend that to claims based...an application connects and indirectly claims it should be authorised to PIIdentity1, PIIdentity2 & PIIdentity3 where PIIdentity3 is a highly privileged Identity with write permissions on the PIARCHIVE table. To me you wouldn't want a connecting application to be bloated with all privileges upon connection when chances are they are not going to use them, connect and then based on the activity request the privilege (which the PI Server would already know about from the claim and pre-authorised it).
I think there is a danger for OSIsoft to keep pushing security outside of the PI Server to the experts with no real fail-safes (I'm exaggerating here for dramatic effect) or native mechanism for securing the authorisation in a more granular manner within the PI Server...but of course I'm no Bryan Owen.
I find this an interesting discussion and like to add a pair of cents from Germany
Rhys @ Wipro
because a user can belong to many roles (piadmin, pidemo, ...)
We generally talk about Identities here when referring to "PI Identities", "PI Users" and "PI Groups". Piadmin and pidemo belong to "PI Users". We recommend making use of "PI Groups" or even better "PI Identities" with PI Mappings.
Rhys @ Wipro
I've always wanted to see in the PI System - you connect as least privileged then elevate depending on what you need to do. Extend that to claims based...an application connects and indirectly claims it should be authorised to PIIdentity1, PIIdentity2 & PIIdentity3 where PIIdentity3 is a highly privileged Identity with write permissions on the PIARCHIVE table.
I understand that you are suggesting something similar to User Account Control (UAC). So let's assume you would connect to a Windows Server OS with UAC enabled via Remote Desktop as a local Administrator to do some maintenance within an AF Database. When launching PI System Explorer, the first message popping up is something like:
"This application may require evaluated permissions ... Do you want to restart it?"
After confirming, you start creating a new Element in AF, what would cause a popup like the following one:
"You are currently connected as 'PIIdentity1' but the action you are about to perform requires 'PIIdentiy2' privileges. Please confirm you would like to reconnect under evaluated privileges."
Assume the next step would be adding an Attribute with reference to a PI tag. This action would require read access to the PI Point's attributes:
"You are currently connected as 'PIIdentity2' but the action you are about to perform requires 'PIIdentiy3' privileges. Please confirm you would like to reconnect under evaluated privileges."
When PI System Explorer attempts to read the tags snapshot, another evaluation is required:
"You are currently connected as 'PIIdentity3' but the action you are about to perform requires 'PIIdentiy4 3/16' privileges. Please confirm you would like to reconnect under evaluated privileges."
Now please ask yourself if before creating the next Element with Attribute reference to a PI Tag you would like to reconnect as "PIIdentity1" to start over again with minimum privileges.
In my humble opinion this is just annoying and even I consider myself an accurate German , I would stop reading the details and just confirm evaluation.
Is your idea about how this could practically work, possibly a totally different one?
Gregor, it is along the lines but it wouldn't have to be a function of the UI and could be handled internally within the AFSDK (for example). It wouldn't be as granular as you suggest I don't think because you wouldn't instantly loose your privileges but rather they hang around for a bit until they timeout and you drop back down to least privileges. Just some thoughts...
I am sorry but I don't get the big picture. If permissions are evaluated and set inside a clients AF SDK session automatically, where is the difference to just assign the appropriate permissions? Do you see the value when it comes to message logging or do you consider communication being more secure?
It's likely my bad that I don't have the insights of discussions about activity based authorization. My feeling is that such activity based authorization with the PI System would increase the level of complexity. Can you please explain what you have in mind?