Tag security is actually
split into two different issues.
The first issue is, who has
access to the configuration of the tag? Now, by
configuration we are talking about things like the
description of the tag or the Zero and Span of the tag.
We are not talking about the data that's associated
with the tag just yet.
There's a second thing that we
can control. And that is access to the data associated
with the tag. So, again, the first issue
is, who has the access to the configuration of the
tag? The second issue is, who has access to the data
that is associated with that particular tag?
Now, we do that using
a couple of fairly straightforward
concepts that you may have seen in other systems like PI.
We associate with each tag a Owner.
And we can also associate a
Group of Users
who are associated with that. And then, anybody
who is not in those two Groups, anybody who's not in those two
Groups is known as the World.
So, anybody who is not the Owner or not in the Group
is -- basically, has World access.
Now, we
do this concept for both the Point configuration
and the data. So you will
notice with Point configuration we have something we call
a Point Owner. We also have
a Point Group. And then, finally,
we have something called Point Access. We will talk
a little bit more about Point Access in a few minutes, but that
basically defines what the Owner and the Group can
do. So now, compared that to the
DataOwner. Every PI Tag has a DataOwner.
It has a DataGroup. That's the Group of Users
associated with the tag. And then, finally,
there is an Attribute called DataAccess, and
DataAccess basically specifies what the
Owner and the Group and the rest of the World can do.
So, let's look at
where you would find these configured, and then we will dig into the
actual definitions and actual
how they -- actually how they work. So, let's -- first of all,
let's make sure we all know what we are talking about first.
We are talking about looking at a tag, using
a Tool like the Point Builder, and looking at its atti... attributes.
So I will look at a tag called Sinusoid,
which we use in training. And,
if I go into the Security Settings, you can
see that it has a DataOwner and
and a DataGroup of piadmin. That is a --
piadmin is the name of the User
and DataGroup is the name of the Group
that's associated with this. Now, that
does not really tell us anything until we look at the permissions.
What does the Owner get to do? And, as you can see, the Owner has read-write
access. The members of the Group have read-write
access. And, in this case, this PI Tag,
the World, has read-write access.
Now that's a little liberal. That would allow
everybody access to this tag.
Let's take a look at a tag that's not so liberally
defined. Now, I am
going to type in the name of the tag I created earlier.
It was simply called firsttag. But if we look at its
security, again the DataOwner
is piadmin, the DataGroup is piadmin, as well. Remember, this is
a Group as well as a Username. That's fine.
Looks a little confusing. And, in this particular
tag, if you notice the Owner has read-write access, but the Group has
read-only access, and so does the World. And that's typical
of a PI Tag. When you create a Pi Tag, the Owner
is piadmin, the Group is piadmin.
And it's only the Owner who has read-write access.
We will talk a little bit about this when we
do our exercise. But, this specifically gives
piadmin access to the data associated with
the tag. And, in addition to the data,
we also have control over
the access to the Point Configuration. And that's handled
through this over here, the Point Access.
Now, let's take a look
at a different application and a different way that we can actually
look at this information. Here's a different way of
editing a PI Tag. Let me
import the tag from the Pi Server.
And, as you can see, it's the same information, just
displayed a little differently. Here we are seeing the Owner
is piadmin. The Point Group,
that's the Group associated with it, is piadmin. And Point
Access -- this specifies what the Owner can do --
the Owner has read-write; what the Group can do --
the Group has read-write; and what the World can do. In this
case, the World has read-write. Now, compare
that to -- let me bring in
firsttag. And, I will import this
from the Server.
Now, take a look at this. Slightly different.
The Owner and Group are the same -- that's the default. But, look at
Point Access. This defines who has access to
editing the Point, and we see here, only the Owner
has read-write access. The Group has read access,
and the World has read access.
Here's a quick summary.
There are three different attributes that control
access to the
configuration of a tag. And those three attributes are:
who is the owner?; who is the, or
what is the Group of Users that is associated with
that tag?; and then, finally, what is,
in fact, the access that's defined?
And that access is defined by an attribute called
PointAccess. And, as you can see, that's where we
specify the three things. That, that's where we specify
what this PointOwner can do. So, you can see, the Owner has
read-write. That's where we also specify what the Group
can do, the PointGroup, is specify
with this Group. And that, also, is where we specify what the
World can do. The World is somebody who's not
the Owner and not in the Group.
Now we can specify that in multiple
places. We can specify that
simply by going and editing the tag, one at a time, using
the PointBuilder. Or, in something like Excel,
we can specify those things en masse
and do massive edits.
Now, a couple of other points about this. You should
notice that -- or you should be aware that
a PI Tag can be associated only with a single Group.
If you were to look at this Builder here, you notice there is no
place to associate this tag with multiple
Groups. It's a single Group.
Also, a User can belong to many Groups.
So, the way you would handle your security needs
is, essentially, by giving people membership in Groups.
That's how you give access to certain tags.
Again, it's the -- if you can think of the
analogy of a User with lots of
keys. By giving people membership to Groups,
he's going to have more doors he can open. And since
a PI Tag is going to be behind one of those doors,
in other words associated with one of those Groups, then people
who belong to more than one Group can generally
look at more things. And, finally,
you should know that we will always grant whatever's
the less restrictive access right. So, let's, for example,
say that -- it's kind of a strange example -- but let's say
that a person belongs
to a Group, the piadmin Group, but,
in fact, the Group only has read access, but the World has
read-write access. If that were the situation, then
we would simply give -- since everybody is
a member of the World, we would give everybody read-write access,
even if they are in that Group. So we grant the less
restrictive.
Now, later on in an exercise, we are going to go over all this
in great detail, so do not worry if you are not getting it just yet.
Wait 'til the exercise and we will go over it in, in much, much better detail.
I do want to point out that the -- there are some
kind of standard error messages
that you are typically going to see surrounding security.
Whenever you see these negative 10400 -- or 401
errors, those are typically error messages associated
with security. And, if I am trying to write to a
value, for example, and I do not have access to it, I will get that
No Write Access. Incidentally, the way you translate
that is to use the pidiag -e.
And let's just go over that real briefly. I am going to go ahead and choose
Run, Command, and
this is going to bring up a Command Prompt. I am going to Change Directory to the
pi-adm directory. And I will do a pidiag -e.
E stands for error message.
And then I type in the name of the error, negative 10401.
As you can see, it, it flags that as the No Write
Access. So, that's how you would translate those error messages.