Let's talk about this overall Database Security Section.
By looking at something we have already worked with, let's look at the
PointBuilder and the Security there, because it's very similar.
So, what we, what we saw in earlier videos when we were talking about
interfaces being able to write to the,
to the Interface Tags using these Identities,
I showed you that this Data Security
Section within a Point Attribute -- this is how we
control who has access to write to this.
In this case I created an identity. That Identity
is being used by this OPC Interface
when it connects, so, because that Identity has
read-write access to the data that's associated with this
Tag, then that means that it can write Values to that,
to that Interface plus the other Tags here.
Now that's how we control who has access
to, to edit Tags, to write Values
to Tags. Okay. If you take a look at our Database
Security, very, very similar. If we go into PIPOINT
this is how we control who has access to
create Points in the first place.
Now this is kind of at a macro level. The individual
Point Security controls who has access to
Points. This controls who has access to the Point Database
in general. So, for example, I will not
be able to create Points in this PIPOINT Database
if I do not have read-write access here.
Now, by default, what you will normally see is you will normally see this
behavior right here. piadmin and
piadmins, this is a PI User and a PI Group.,
They both have read-write access. And, PIWorld has
read access. Now, what this means is,
well, first of all, it means that when I am working within the
local computer here, on the PI Server itself,
since when I log in,
you know, locally, I am logged in immediately as piadmin
with complete permission to do everything. You know, this means
basically I have free run to be able to create things
when I am doing this locally. But remember, that's only for people who are
logged in to this computer. When I log into this computer,
the local PI Server, then I get connected
as piadmin. When you want to do something remotely,
you are going to need something better than that. You need something to create
an Identity that has permissions because you do not want to be
logging in as piadmin or in the piadmins Group.
We suggest you use Windows Integrated Security for remote access.
And for that you will need a sec...you will need to create an
Identity. Now, this gives the same for
other Tables as well. I just showed you the PIPoint Table
'cause it's a good starting point, but if I want to
control access to who can create other identities, I do that
through the PI User Table. It has the same configuration.
The modules in the Module Database.
You know that's all done through this Table here. And, on and on
through these Tables that are, you know, that are described in your book.
Anyway, in order to,
to give people access to this, I will, I will need to create some kind of
an Identity, and then make sure that Identity has
read, read-write access. So, one of the things
I can do is -- let's look at our existing
Identities. Yeah, let me just designate one of these. I am going to
say anybody who logs in as a
Supervisor who is mapped to this
Identity called PI Supervisor, we want them to
be able to have read-write access. Now currently, I have got a
few Windows Users who are mapped.
Here, here's the one I would like to show you right now. It's a User
named Sal. He's in the domain called VIRTUALLABS,
and he is mapped to this PI Identity
called PISUP. Well, what permission does that give him
with regard to the Point Database?
Well, absolutely nothing. Because, if we take a look here,
PISUP's not mentioned here. So, first of all, I would have to add
this User as a, or add
PISUP as an Identity, and then I would have
to grant that Identity some privileges. I will go ahead
and Add. And then the next thing I would have to do is
I would have to make sure that Identity has read-
write access. So, I will go ahead and say read-write access
to that PIPOINT Database. Now, that should,
you know, by, by the benefit of having done that
right now, that should give Sal
the ability to create PI Tags.
Let's demonstrate that. First of all, let's remove that ability.
I will go ahead and just give them read access. And I will give --
I am going to go ahead and log on to my
Remote Node here, and I am going to log
on to this PI SMT, this
System Management Tools. Let's log on as Sal.
So I will go into this -- ...
I will do a right click while holding down Shift on here.
I think I have to hold down Shift to do a Run As.
Let me see. It looks like
you can just right click on that. Choose the Run As.
And I am going to Run this as the Windows User
called Sal. So, I am choosing to Run this,
not as who I am currently logged in as. Now, this
User is in the domain called VIRTUALLABS.
And his name was Sal. I will go ahead and type
in his password.
And that should log me into the PI System Management Tools
as the User, Sal. I can verify
that by going into Connections. I can attempt to do a
connect, and as you can
see it has now connected me as that User called
Sal. So let's see what happens when I try
to build some new Points. If I go into
the Point Section, into the PointBuilder,
and I, I have already got -- let me go
ahead and select that -- I forgot to select my server first --
now I already have three,
three Tags that are getting their data
from the OPC Interface. Let's say I want to create a fourth Tag.
Okay. Yeah. So here,
here are some three, these three three Tags here. I have got PumpSpeed_Test,
etc. I will do, I want to add a new,
a new Tag called -- I will just call it Test2.
So the easiest way to add a new Tag is to just go into
an existing Tag, and let me go ahead and just rename
it. I am not going to change anything. Everything
else looks good. And now, watch what happens when I try to save
this. I attempt to save it
and right now it's saying, giving me this Failed to create point.
It's giving me the infamous negative 10401 error.
Very, very common error. We see this all the time.
It's basically indicating that we are trying to write to something, but we
do not have permission to do that. So, how can I give myself
permission? Well, let me go back to the server,
to the Home Node, and on the server
let's give Sal, by way
of his Mapping to this Identity, let's give Sal write
access. I will go ahead and specify write access to the PIPoint
Database. Let me go back to my Remote
Node,
and since I have not tested this first, this ought to be a moment of
high drama. I will go ahead and try saving
and let's see. Did it work correctly? Yes, there we go.
So it's successfully created that PI Point,
as I expected it to. And,
the reason I was able to do that is now Sal, by way of his
membership or his, his Mapping to that Identity,
and because that Identity now has read-write access to the PI Point
Database, now he can create Tags.
What we have been discussing so far is
how to give somebody the ability to
create new Tags. Well, watch what happens if I,
if I remove Sal's
read-write access, or write access,
from that Point Database. You will notice, even though he
does not have the ability now to create Tags,
if I were to create a Tag now, he would not have that
ability. Even though I have, I have
not given him access to that, the only thing he would need
to edit existing Tags is
if we go into the Points
themselves and then designate Sal.
Or PISUP, you know, and, and, and therefore
Sal, and designate PISUP having read-write
access to this data. So, let me demonstrate.
See, I, I will, I will go ahead and just verify now
that we have, we have successfully hobbled
Sal so that he no longer has read-write
access. If I go ahead and try saving this as
Pump Test, PumpSpeed_Test3, --
let's see what happens when I try to save.
Yeah, see, now we are getting that same error again.
And, so, we have, we successfully
disallowed him to be able to, to write to that,
but watch, if I were to, you know, working
as piadmin now 'cause I am back on the server,
as piadmin I can go ahead and make PISUP
a, a, somebody who has read-write access.
So I will go ahead and add PISUP to this
existing Tag
and then I will give PISUP
a write access. I will make sure I
save this Tag. So now, this PumpFlow
here, as you can see, unlike the other two,
the other two tags here, PumpFlow now in,
in its Point Security, has PISUP
having write access. What this means is
that I should be able to go back into my other machine,
using Sal, and be able to edit this PumpFlow.
So let me go in and see if I can change the Descriptor now.
I will go back into my Remote
Node here. Yeah, here's my PumpFlow.
Now, remember, I am logged in as Sal, and Sal
did not have permission to create.
I will just change this and I will go ahead and
try to save. Now, right now the error message says cannot
write to that. I will go ahead and save. And it looks
like it was successfully edited. And if I go
back to my Home Node, if we
refresh this screen, we should see,
see, that, that edit did work. So, that's the one
point I wanted to make. It's kind of a subtlety, but what it
means is that when you are working within this database,
if you want to grant somebody access to
edit existing Points, you do not need to do anything
for him here. The fact that he has, you know, he has the
permissions of PIWorld means he has read access to the
Point Database. As long as he has read access to that
and then read-write access
here, as long as that's the situation, he will
be able to edit existing Tags. But, when it comes to creating
new Tags, for creating new
Tags then, or new modules, or new Users,
etc., he would be required to have read-write
access here, and that would go ahead and grant him
permission to build brand new Tags.