Tip:
Highlight text to annotate it
X
Section 7.0, Security.
The objectives in this section
is we'd like to go over how you'd configure
PI SDK connection. We'd like to
explain how to manage the contents of a Firewall table.
Create users. import Windows
domain users into the PI User table. We will create
groups and we will describe the limitations of those groups.
We will assign users to groups. We will configure point security.
Something called trust accounts for interfaces. And
understand the use of the $ in trusts.
Configure database security, so only certain people have
access to certain database entries like Points and Archives.
And then finally be familiar with PI Security
Best Practices white paper.
So let's start by just discussing security in general.
You may see, as you work with PI,
either of these error messages.
And of the two, the one I think you'd be the most
likely to see is this one right here.
We see this more than just about any error message.
And it typically happens when somebody
tries to configure an interface node for the first time. See they have
interface that is running remotely, and it has to store
data on a PI Server. But unfortunately, it does not
have write access. So we typically see
-10401 error and just as quickly as we see it,
we usually tell people that they need to create a trust. Because
that is typically what people forget to do.
So that's what we are talking about. This is security
related and basically this whole chapter is all about security
and these are two of the things that you will see happen most frequently.
We would like for PI
to have whatever
permissions that you think are
appropriate for all the users and all the applications that
have access to PI. So we want to make sure that those users
and applications do not get these messages.
So how do we go about doing this? What options
do we have? Well we create users and
groups. So you can create PI Users and then associate those users
with certain groups. And then those users actually
become very important later on when we define trusts. Because
when you define a trust, you assign
what PI User
the trusted application uses
for its permissions. So basically
in order to understand trusts, we need to understand users
first. A trust is for
allowing permissions for those things
that will not have a user who is interactively
entering a password and a username. And then
also, we have configuration control
over the database security itself. This
would be not answering the question,
who can edit tag B
for example. But answering the question,
who can edit tags at all? Who can create new tags?
So if we have
got, for example, tag X and somebody would like to edit the
data, you have control over that on a tag by tag
basis. But also you have database level
control-- who gets to even look
at those security settings to make changes to that.
So those are some of the options that we
use for implementing security in PI.