In a previous video on Windows Integrated Security
we talked about making use of these PI Identities
along with these Mappings here to map
specific Windows Users and Active Directory Groups
to the PI Identity, thereby granting access to
PI. Now let's talk about how we use these
identities as a way of assigning
who gets to edit what PI Tags.
How to, essentially, allow or disallow editing
to Tags and certain attributes of Tags.
So let's go over to our PointBuilder.
And in our PointBuilder I have got some, I have got three Tags here,
and within these Tags I am looking at
the Security Tab. So, down here we can see
that there is a Point Security Definition Area
and that is where we assign which identities
have specific types of access to
editing the Point Attributes. And, when we say Point Attributes,
what we are talking about is when we look at a Tag
it's got, it's got things like a description,
and if we look at the Archive Setting
it's got a zero and a span, etc.
And it is through this section here,
Point Security, that we determine who has access to that
and what type of access they have. We also have a
section called Data Security. Now Data Security has to do,
not with the attributes of the Tag, but with the data
that's collected and stored in that Tag.
So, two different sections, and the
mechanism that work...at work here is that we
assign a PI Identity to those
Tags that we would like to assign certain,
you know, privileges to a, to a certain individual
who maps to that identity. In other words, if I
would like all the Supervisors to be able to edit the
attributes of this Tag right here, BA TEMP, then
what I need to do is I need to create an
identity that maps, you know, to all of the
Supervisors when they log in, so, you know, these
Supervisors through the mechanism that we described earlier,
through Identities, those Supervisors would map to
an Identity called PI Supervisor.
And then, by assigning PI Supervisor
as one of the Identities associated with this
particular Tag, with the Point Security, we can
determine exactly what that Windows
User can do. And, in this case, what we have done is
we have assigned read access and write access
to anybody who's in that, or associated
with that particular Identity. So, so what do we really
mean by that? Well, here's a PI Tag called
BA TEMP1, right? That PI Tag
has associated with it in this section right
here, in the Point Security Section, it's associated that
PI Identity. That's something anybody can do.
I can go in here if I have permission, and I can add
new identities to associate with that Tag.
Now, adding an identity, in and of itself,
does not really do anything until you specify what that
identity is allowed to do. So, in this case, I am
saying anybody who maps, you know, their Windows
User to that identity, to that PI Identity, he gets
read-write access. Now that, remember, is to the
Point Security. Now, in addition, we have this
Data Security, and that is separate. That's the,
you know, access to the data associated with
the Point. And I also said that anybody
who maps to this PI Supervisor Identity here,
that, that mapping there
or that Identity grants people read-write access.
Now, if I want, I can create a
PI Identity for every Windows User you have.
But I think what is more typical is you will find that people
will create identities that look kind of like this.
Here's some Identities that are specific for
different, kind of, roles for within PI. Here's
one called PIEI. That's for the Electrical
and Instrumention people, the E&I folks.
Here's one for IT. Here's one for the people that are doing
Lab Samples. Here's one for the Operators. Here's one
for the Supervisors. So, typically, what you would do is,
through a mapping over here, you would map
individual Groups of Users or Active Directory Groups
into those specific
Identities. Now, we are actually not going to go into the
details, in this video, on how to map using
these mappings, these Active Directory Groups, to these Identities.
Please go out and take a look at that video on Windows Integrated
Security for that. But suffice it to say, at
some point you have mapped all of your Windows Users
to these PI Identities, so that all the
Windows Users who log, all the people at your plant who log in
as Supervisors into Windows, they are associated
with this Identity called PI SUP. And then, as
that, as members of that Identity, they get all
the privileges that that Identity has in PI.
If I go into PointBuilder you can see
they do have some privileges. In this case they have read-write
access to both the Point Attributes and the data associated
with this Tag. And, I can add them
to other Tags as well. So, you know, typically,
of course, you are not going to be doing this one Tag at a time.
You'd be doing this to tens of thousands of Tags all at once
using our Tag Configurator or something like that.
But, as you can see, this is the concept here. I can go
ahead and add individual -- there we go --
individual Identities to these Tags.
And again, just adding the identity,
that does not accomplish anything until you have defined
what that identity gives him permission to do.
In this case, the default was read access. I am going to
give him read and write access.
I will do the same thing over here.
Here's my Supervisor Identity.
And now I will give them write access to this Tag as well.
So, we can go ahead and do that for all the Tags. We can do it in,
in bulk, of course. Now, I have been glossing
over something here. I have not really pointed out
what these things are. This piadmin, piadmins,
and PIWorld. Well, piadmin is a User,
a PI User. Yes, we still do support PI
Users, and, and the only reason I would suggest using
what we call PI Users is if you are supporting a Legacy
System that was installed before we had Windows Integrated
Security. See, at one point, the only
mechanism we had for security were these PI Users, and
also something called PI Groups. piadmins is a PI
Group. We do not suggest you use that as the
primary mechanism because, as, as I just demonstrated,
it is so much more
powerful to be able to associate
Windows logins with Identities,
and then have those Identities map to,
you know, individual Points and Permissions. But we do
still support these, but we do not really recommend
you use those if you are not in the process
of supporting a Legacy System that was configured when that
was the only solution. Now, the other thing I did not point out
is we also have a PI Identity called PIWorld.
And all the Tags in PI, by default,
are associated with PIWorld,
as you can see. That's just, you know, that's the nature
of these Tags. By default, if
you have permission to join to the system,
you know, as an identified Identity, that give...
That grants you the same privileges as PIWorld which, as you
can see, means you get to look at the Tags in PI.
Now, take a look at this Tag right here. Let's pretend
that this BA CONC.1, let's pretend that that's a
Laboratory Tag in which we would like all of the
Supervisors to have read-write access to both
the attributes that define the Point itself, things
like it's zero, it's span, etc., and also, we
want them to have access to the data collected, you know, and, and
stored as Lab Results. But, in addition to the
Supervisors, we also want Lab Technicians to have
access, not to both the Point and the data,
but we want the Lab Technicians to have access to the data,
because sometimes when they make mistakes, or discover they have to re-sample
something, they want to go in there and fix the data. Right?
So they need access to that. They do not need access to this.
How would we go about doing something like that? Well, the
first step would be to map the Supervisors
and the Lab Technicians to two separate
Identities, as we have done here. And, again, we are not going to get into
the details of how to map them. Go out and look at that Windows Integrated
Security video for that. But, now, once we have
got those identities, go into the PointBuilder. For this Tag
right here, let me go ahead and add the Supervisors.
And I will also add
the Lab Technicians. As you can see, you can do more than one.
There we go. This time, you may
have noticed earlier in the video I, I added
Supervisors, but I did not save it. So you are going to have to
Save after you do this. So I will go ahead and add
them, the Supervisors, to both the --
there we go -- the Supervisors
and the Lab Technician Identity
to both the Point Definition and the Data.
So, for the Supervisors, what we
would like is we want them to have read-write access to the Definitions
of the Point, and,
and also we want the Supervisors to have read-write
access to the data collected by the,
the, or for that Point. I will go ahead and save that.
For the Lab Technicians -- they do not, in fact,
need read-write access to the Definition
of the Point. So, this Point Security over here, this is
something we can just allow them to accept
the default there, which is read access.
However, for the data that's associated with this Point, we
do want the Lab Technicians to have write access,
so that will accomplish that. I will go ahead and save my changes.
Now, anybody who logs in as a Windows User who maps
to the PI Identity called PI LAB, he will
now, because of this, have read-write access
to the data that's being stored in those Lab Tags.
By the way, those of you who are managing a
system that predates when we integrated Windows
Integrated Security into PI. You may notice
that now we do have the ability to associate more than a
single PI User or PI Group
with these objects here, these Tags here. That is
something brand new. So, you can do any number of Identities plus
any number of Users and Groups. And here's
a, kind of a, a thing you will figure out
about Users and Groups. Users and Groups are really just
a, a type of Identity nowadays.
So, you can really think of all of these of, as Identities.
I would suggest, you are starting from scratch, you would
go ahead and treat all -- or go ahead and create
Identities at this point. There's no point in creating those Legacy
PI Users and PI Groups. Now, that's
the end of the video if you understand
it all. If this makes complete sense, you are good
to go. Go on to the next video. However, for those
of you who are a little bit lost, two things. We have an exercise coming
up. Look for the video on the exercise of this.
We go through this in great detail, as well. And,
if you'd like, let's just stick around
and go over a real quick analogy of how
security works. Here's the analogy. Imagine that you have got
a PI Point, or really, a PI Object of any type.
I have been talking about PI Points, but this can be any secure PI Object,
like, for example, a module in the Module Database.
Now, that PI Point,
imagine it's inside this little box here.
And, we can kind of look into the box. It's got see-through walls
there. And, of course, we have got more than one Object, we have got
hundreds, maybe thousands of these PI Tags, so imagine
that this list goes on and stretches
on, you know, for tens of thousands of Tags in
this direction. All of these need to be configured with
Security. So, how does the Security work? Well, you can
think of Identities as
though they were doors. Because, see, without doors, you
really cannot get to that Object, right? Now, when I say
Door E on this secure Object, or E here,
and then we have got Door E and Door S, that just means
we have got multiple Identities associated with that Object.
That would be the equivalent of -- let's
go back here to our, our
PointBuilder. That's roughly
equivalent to, you know, this, this is the Object
right here, BA CONC, and this would be equivalent
to Door S, you know, Door L,
for Lab. These are the different doors that
grant you access, that are built into this
secure Object here. Now, what
access are we giving people who -- or, what
access does this door really grant? As you can see,
there's read-write access and there's read only access.
Well, going back to our analogy. Imagine,
within these doors, you have got
some doors that allow you to just, kind of,
peek into the little window here. Okay? That's the
equivalent of read access. So, these
doors right here are configured so that we can look.
We can just kind of look through the peephole. These doors over
here, the ones with the big
star on 'em, that's read-write access. That's where we are
going to grant you the ability to unlock that door,
open the door, walk right in, do everything you want with that
Object. Okay. As you can see, that is
something, that construct right there,
the construct of read vs read-write,
that is something that is apart from the
door itself, from the Identity. As you can see,
this Door E, that's an Identity. That's
got read access in this case. But, in, in this case over here,
it's got read-write access. Well, how is that managed?
Well, again, that's because back here, when we --
let's, let me select this
right here, or actually, let's, let's go to Lab.
If you look at this Identity, this is called PILAB.
In this case, it's got read
access, but when used over here with this
secure Object, it's got read-write access. So, you can almost
think of this, you know, this right here, as a
modifier for that door. It tells us what type of door it is.
In this case, this is a door that only allows read access. This
is a door that allows read-write access.
Okay. So far, so good, hopefully.
A Mapping is like a sign that you hang on the
door. Remember, I said these doors allow you in.
If I have access to Door E,
which has read-write access, I can just walk right through,
I can get to the secure Object. Well, how do I know whether I
have access to Door E or not? Well, I
know, because some nice person has hung
a sign on that door
that says, Engineers, enter here. That's
the equivalent of a Mapping. When you configure a Mapping,
it's like drawing a little sign on that Identity saying
okay, everybody who's in this Active Directory
Group, you get access. So, for the Supervisors here,
we have put a little sign on this door here
saying, you know, this is the Mapping that
says, Supervisors, you get access to Door
S. And, in the real world,
or I should say in the PIWorld here, this is actually
done through Mappings. So,
when, when I configure a Mapping, what I am doing
is saying this Windows credential is
associated with this PI Identity. It's basically
hanging something on that door. And as you, as you will
notice, you can have hang --
let me go back to our analogy -- you can hang
multiple signs on the same Identity.
So, there's no problem at all
with having multiple Groups,
Active Directory Groups, associated
with a PI Identity. If we go back here,
let's go ahead and take a look at our,
our current Mapping here. We can see
that I can add another Mapping that maps
a second Windows Group, Active Directory Group,
to this same Identity. Now you can,
you cannot map multiple Windows Users, but you can map
multiple Groups. So if I do a new Mapping -- let's go out
and find a different Windows,
Windows Active Directory Group. I will look for all the
Groups that begin with the letter solution.
And, here's, here's the -- let's go with the
Lab Technicians. Here's solution_LAB.
That's an Active Directory Group.
And, as you can see, I can map that to a,
a PI Identity, the same PI Identity
we mapped to previously.
So, now I have got two different Windows
Mappings to the same PI Identity, and that's
roughly equivalent to being to hang multiple,
multiple of these signs. So, so,
basically, this is the equivalent of saying, hey everybody, every...anybody
who sees their name on this list, you come on in through this door.