In the previous video
we learned what are identities,
mappings and trusts and how are they
used to configure PI Data Archive security
in a way that allows us to control
who or what really gets access and to tailor
the permissions in the most manageable way.
In this video we'll be taking
a deep dive into this map to discover
exactly what are those security
areas on the Data Archive?
And what security defaults are already
in place in new PI Systems. And should they be
leveraged. You might have also heard about
PI Users and Groups and be wondering
how do they fit into this map. So we'll look at that.
And finally we'll also look
at why specifically we use
trusts for PI Interface instead of
mappings. And are there any other times when we should use
PI Trusts.
To start off with, let's define the
different security areas on the Data Archive.
What are those?
On the Data Archive there is something called the Database Security Table.
And this table is divided
into different areas that correspond
to groups of related tasks.
For example, one of them is
PIBackup. And PIBackup
as the name implies really
deals with the permissions for
who can see the results of previous
backups or perform backups of the
PI Data Archive. There is another
area, PIPoint, and PIPoint
controls top level access to PI Points.
And again this
Database Security Table is not just divided into these
two areas but many other areas.
But I want to really focus your attention and talk
more about PI Points. And that's because
it's so important for any
user to see
data for even one PI Point. You might've also heard the
term PI Tag used for PI Point, they are the same thing.
They are going to need some
permissions on PI Point.
And when we talk about the permissions,
those permissions are
divided into different actions. For
example you could have read permissions
and you could have write permissions and you could have
no permissions. And remember
that the PI Identities themselves
are the ones that get assigned
read, write or no permissions
on these different areas of the
database security table.
Let's take PI Point for example. Maybe
our process leads need to be able to
create new PI Points.
And therefore they would need
read write access on PI Point.
When we talk about read, that's the same as being able to see
something.
Now I had mentioned when I
explained that
PI Point corresponds to controlling top level
access to PI Points, if any of the
areas involves top level access, that
means that there are additional permissions of
security on a lower level as
well. And in the case of PI Point, those individual
security access permissions are set
on each individual PI Point
as well. On each
PI Point, there is
obviously the settings for the PI Point and
there is the data for the PI Point. And
security can be configured separated on both of these.
The ability to see
or edit the configuration as well as
the ability to see or edit the
data itself.
And just like with the Database Security
Table areas, the
PI Identities get assigned
the permissions on
this level as well.
Now we've discovered what those
areas are. There is the database security table and
that is divided into
different areas like PI Backup and PI Point.
And the PI Identities get assigned
read write or no access
on these different areas. And that
dictates what they are authorized to do. In addition
to the Database
Security Table which covers high level
access in certain areas. There maybe
settings on individual objects as well
like in the case of PI Points, there
are individual security access that's
setup for both configuration and data.
Since the PI Identities are the ones that are getting assigned these
permissions, let's now focus on the
default PI Identities and what permissions
they may or may not have
per-defined on new systems.
In the previous video I mentioned
that one of the default PI Identities
was PI Supervisors but that there
were other default PI Identities.
We also have PI
Operators, PI Engineers and PI World.
I'm going to focus your
attention on PI World because
this default PI
identity has read access to
many of the database security table
areas by default.
And PI World, what is PI World about?
PI World represents
the concept of everyone
and it basically means that all
authenticated users on the PI Data Archive
automatically gets the access permissions
defined for PI World in addition
to any other access permissions that they may have been granted.
You can disable the PI World identity
and doing so improves your control over
the access to the PI Data Archive because
when PI World is disabled,
all the users only get the access that's specifically
configured for them and
no more. For example let's say that
we have all
company that each employee at our
company uses the PI System. But maybe
we have some external consultants
and we want to make sure to very specifically
tailor the permissions that these external
consultants have.
The easiest way for us to do this would be
to create custom PI Identities
that match up exactly to the user groups
that we have in our organization. So for
example, say that we have process
engineers, process leads, all of our
employees as well, and these external
consultants. We can create corresponding
PI Identities for our process engineers, process
leads, all company and consultants and
we can disable the default PI World identity.
Now disabling PI World is not
something that you should do lightly.
In a new
system, you should certainly consider disabling
PI World because you don't have
any pre-existing connections or
users or applications that
are relying on PI World access. However
in an existing system disabling PI World
could unintentionally
lock down areas of access which would be
dangerous. And it can be tricky
to determine which users or applications
might be relying on PI World access.
So in these situations it is
absolutely important to make sure
that you have
moved all of your users or applications away from using
PI World before you disable it.
And for more details, definitely
consult the documentation.
In addition to customizing your PI Identities to
match your users and applications,
remember like we saw earlier, we
need to be able to link our users or our
user groups to their specific PI
Identities. And we do this with
PI Mappings that match up
our Active Directory users and groups to the corresponding
PI Identities. Remember also
that if we can leverage our Active
Directory groups, then we'll only need to
create four mappings, one for each group,
versus creating mappings for all the users within these groups.
You may have noticed
that we haven't specified
a PI Identity that matches up with our PI System
System Administrator. Now we could've done
this, however there is actually
a existing
item on the system that we can use to
easily grant all the access for our PI System
Administrator.
Before PI Identities were introduced on
the Data Archive with version 3.4.380.36
there was something that was used
instead called PI
Users and PI Groups.
Now PI Users and PI Groups still exists
on the Data Archive to support backward compatibility.
And there are some default PI Users and PI Groups
that exist even in new systems.
And one
of these PI Groups
specifically, PIAdmins
with a 's' can be a quick way
to get your PI System
Administrator setup with all the access they need.
The reason why this is the case is because
on new Data Archive
installations, PIAdmins by
default is given
read write access to all the areas in the
database security table as well as the other
permissions. So by default, PIAdmins
has write access to absolutely everything
on the Data Archive. Now if
someone is truly a PI System Administrator,
that's exactly what they need because a PI System Administrator
needs to be able to do everything on the
Data Archive. And because there is not
any type of customization that
we would necessarily be doing, linking our
PI System Administrator to the
default PIAdmins group is a really quick
way to set them up with the permissions needed.
And just like the
PI Identities, we can also create Mappings
to the PI Groups. So we can map our PI System
Administrator to PI Admins
with a 's.' The reason why I keep emphasizing
the 's' is
because there is actually a PI User
instead that's PIAdmin, no 's.' However
we do not want to map any of our
users to PIAdmin.
PIAdmin is designed
to be used only in the
case of recovering from a lock out
on the system. And it's not something
that we need to assign any user on our
Data Archive. So we are going to
say no to PIAdmin
and yes to PIAdmins only.
And the other defaults
we don't need to use. Now that we have
a plan for
mapping all of our user groups
to PI Identities, what about our applications?
Now in the
previous video we discussed
that we would be creating PI Trusts
for our PI Interfaces.
Let's explore why we specifically why we need to do this.
In this example you can see
that PI Interfaces is not the only application I have.
I also have PI Coresight.
And you'll notice that while we
have identities for PI Coresight and
PI Interfaces, PI Coresight I have
setup to use a mapping. And PI Interfaces I have setup
to use a trust.
Now why is PI Coresight
using a mapping and PI Interfaces
using a trust? It's all based on
the protocol that the application uses
to connect to the Data Archive. Our PI
Interfaces use the PI API protocol
to connect to the Data Archive. And because
they are using the PI API, they have to
use PI Trusts as PI Mappings will not work.
That means that any applications that you
may have in addition to PI Interfaces
that use the PI API to connect to the
Data Archive are also going to need to use PI Trusts.
However any
applications that you have that use the PI SDK
or AF SDK
and newer protocols to
connect to the Data Archive are going to be able to use mappings.
PI Coresight fits this so we
can use a mapping for
PI Coresight where we just link the account that PI Coresight
runs under to the PI Coresight identity.
PI Coresight is not the only PI application
that can use mappings.
Another example is PI Buffer Subsystem.
PI Buffer Subsystem is typically used
with PI Interfaces to buffer the data
and the newer versions of PI Buffer Subsystem
connect in a way that supports mappings.
So we can use mappings for that as well.
So when determining
for an application whether a mapping or
trust can be used, just use trusts
only for your PI API applications and
use mappings for your applications
that connect with the PI or AF SDK.
In summary,
when we talk about PI Data Archive
security, it's all about customizing
our PI Identities to match up to the
users and applications at our
organization. Remember these PI Identities
need to be assigned permissions
on the Database Security Table
and other areas. And those permissions
could be read, write or no
permissions at all. When it comes to users and groups,
we learned that those are
the predecessors to PI Identities
and in our new system PI Admins
could be a nice easy choice for our PI System
Administrator where we are going to avoid using
the other ones. And finally when
it comes to knowing whether or not
you should use a trust, remember those are only
for the PI API applications and
in general that means PI Interfaces.
Our other applications that use the PI or
AF SDK, can use PI Mappings.
And whenever possible we want to use PI Mappings
because they are the most secure authentication method.
Now that we understand the concepts of PI Server
security, specifically for the Data Archive,
let's get started configuring that in our PI System
in the next videos.