Okay, let's say you have got an unattended application
like an Interface or the Buffering Sub-system.
And you'd like that, that application,
running on a foreign computer, to be able to connect to your PI
Server without, you know, a, a
user. That's what we mean by an unattended application. It's just going to
be able to connect without have to connect as
a specific Windows user. Well, the way we do that is with
a Trust, and in this video we are going to build a Trust.
But before we actually build a Trust, let me remind
you that, that a Trust is just one of the ways to
connect to the PI Server. There are actually three different ways
to connect to the PI Server. We have not really discussed Number 4.
But, if you go into File and Connections,
to bring up this Connection Manager, and then you take a look at the options.
There's a real nice little
widget here that helps to explain, and also
allows you to configure the different
order in which we handle Security.
First and foremost, we are
asking for people to use Windows Security, or we suggest
you use Windows Security for all of
your incoming attended connections. Now,
attended connections means those being used by a user.
You know, anything with a User Interface. And these are all
SDK-based. SDK is our Software Development
Kit. The SDK passes
the Windows User Name and Password to the
Server, so an incoming client that's using the SDK
has the ability to pass the Windows User
Name and, and the Windows Domain.
And because of that, that's the absolute most secure
way to connect to the PI Server -- using Windows
Integrated Security. And so, that's the first thing we
try. When an incoming client attempts to connect, we
first try with Windows Security.
The second thing we try if that fails, with that same
incoming connection, we will check our Trust Database
to see if there's a Trust that
exists for that coming connection. And you know what that's like?
That's, that's basically like the guy, the bouncer, that's
sitting, you know, next to the backstage door
saying, hey, we are not going to let anybody in unless they are
on the list. So, he's got a list. He's going to
check who's on the list and allow people that match,
you know, what they are looking for to bring in. So,
and we will talk more about that in just a bit. That's the
topic of this video. And then, lastly, if there is
no Trust for that incoming connection, we fall back to
the third, the, the least
stable I should say, or the least secure way,
which is to use the old User and Password
from the PI System. That's probably
not even going to work on your system any more, because on the more modern
systems we suggest you disable that. Let me
explain what I am talking about. When you have a connection
defined, and a connection to a PI Server,
you specify a Default User Name. Now,
that's a PI User Name. The PI
User Name, or I should say PI identity nowadays.
That, that User Name is going to be the one
that we will attempt to connect with
if we get to this level of doing the connection.
Now, if that User Name has a Password then that might,
you know, require a, a Password to be,
a prompt to appear and then user supply the Password.
And, of course, we do not want that for things like Interfaces that are unattended.
So, you know, we, we certainly do not suggest
that you make use of this. And, in fact,
if you take a look at our Security Settings,
it's one of the things we recommend that you turn off --
this Explicit login. We
suggest you disable that. If you go into the Help
for PI SMT, under this
Security Levels, you will see that we, we suggest
this, this as a recommendation
just in general for PI Servers that are using
the Windows Integrated Security. So, chances
are, you have probably got that feature turned off anyway. So, that's,
that's probably not, or never going to be attempted.
Whoops. That's probably not
going to be attempted, you know, this third method here.
So, what we are talking about right now is this one right here,
the Trust. This -- let's forget about this
for right now. Incoming, unattended applications
are not going to be using Windows Integrated
Security. And the main reason for that is because most of these
unattended applications are API-based, and the API
simply cannot pass, as part of its connection
credentials, the Windows User Name and the Windows Domain.
So, that's simply not available for most
of the clients that are connecting that are unattended. So,
instead, we use the PI Trust.
So, let's just go through, just briefly, what the,
the kind of sequence would be
when you are getting access to the Server
from any connection, really. If you have
got -- in this case, we have got a Data Acquisition
Node. This is an Interface that's running over here. It's
trying to connect to the PI Server. So, what
it's going to do is it's going to present
some connection credentials to this PI Server.
Actually, it's more like the, the PI Server here is actually what's going to
go ahead and derive those connection credentials. Now,
if it's an API-based connection,
which most of the Interfaces are, then the
connection credentials are going to consist of only,
well, three things. It's the IP Address and
from the IP Address we can derive the Host Name using
reverse lookup, although, that will add a little bit
of time to the connection, and also we can derive
the Name of the Application. And
as you saw in the previous video, the Name of the Application
could vary, depending on how you have configured it,
and also whether it's an API-based Application
and what version of the API you are using. So there's a lot of variables there
for what the, for what that name is. Anyway, we take
those connection credentials and we
take a look at that set of
credentials. We compare it to our Trust Table. And,
if those connection credentials match what's defined in the
Trust Database, then we will go ahead and associate that
incoming connection with a PI identity. But remember, we
do have to make sure the identify we associate with that
Interface -- you know, when we, when we make this matching here.
When we match those two things up -- we better make sure
that that identify has permission to write
to the things that are required over here. And, typically, what we do for
an Interface is we match it to an identity that has permission
to write to just those Tags that are associated with that
Interface. Now, let's take a look at what's
currently configured on your PI Server in terms
of these Trusts. If I go into Security
under Mappings and Trusts,
I will choose the Trust option. You will find, by default, there's
always an existing Trust. This is what we are calling the Loop
Back Test Trust. It's, it's basically a, a trust
to go to the current machine, 127.0.0.1.
If you are not familiar with that, that's an IP Address
that's, it's basically a reserved IP Address that means the machine
itself, the machine that we are running this on.
So, this, what this does here is it tells me that any application that's
running on the PI Server, any application,
by dint of this Trust here,
that application is going to get the privileges of PI Admin.
And that's, you know, we do that so that things like SMT and
other things you run on here will be able to do what it needs
to do to manage the PI System. And here on this system,
we have already got some Trusts that were configured for a previous
demonstration. I have got two Trusts set up for the
OPC Interface: one that is
API-based, that's the Application Programming Interface base,
and one that's SDK-based. And the big difference between
the two of them, if I can take a look at their Attributes,
here. The big difference between the two of them
is, the one that is API-based -- this is API-based --
is using an application name that's the first four
digits in the application name
of that OPC Interface. And I got that from looking
at the Message Log when it tried to connect. It's the first four digits
of that plus the letter E. E stands for Ethernet.
So, that's the application name, but that's not
the only restriction on the
inco...you know, on this particular Trust. There's also the restriction
that we are only going to allow somebody who's coming from this
specific IP Address. So look at the strength of this Trust.
This basically is saying, if it comes from this,
this IP Address here, if the incoming connection
comes from that IP Address, and if it
has that as its name, then we are going to go ahead and
give it all the properties, or all the privileges of the
user, or the identity of PI_OPC.int.
Now, that's an identity who has permission
to write to the Interface Tags, to the Tags that are collected
by that Interface. And so, this is an,
an Interface that we call PI Interface Node.
Now, I created another one called PI Interface Node_SDK.
It's got the same
requirement as, as to the IP Address
but, instead of the Interface Name,
that other Interface Name we saw -- where was that? Right here --
this OPCpE.
Since this is an SDK-based connection
that we are going to be allowing, we are using the full name
of the executable. This is actually case-insensitive,
so I did not need to use capitals there. The,
with regard to the API-based, that
actually is case-sensitive. So,
two different Interfaces. And the reason
I am doing that is because that particular Interface happens to use both
the API and the SDK. Now take a look at
this particular Trust. This is a Trust that
allows the Buffering Sub-system to get access.
And, it is SDK-based. The Buffering
Sub-system only uses the SDK, so I do not need to
create two Trusts for that. I just need to create a Trust that
allows that by its User, or by its
Application Name, or File Name, there, and, and
coming from this IP Address, we are going to allow it to have
the same privileges of that PI
Identity, which means it's going to be able to go ahead and
write Values to those Tags. Now, I could have made a
much more liberal Trust. I could have done something like
this. Let's do a brand new Trust.
And I will use the little wizard here. Yeah, I could have
created a Trust called, you know, myBadTrust --
because this is not what
you are going to want to do -- and I could make this let's
make this API-based. So, for the
Application Name, I can leave that blank. And then, for the
IP Address, I can specify,
what is that? -- 192.168.70.204.
Now, we will get
more into what this NetMask means. Just
suffice it to say that 255, and all four
octets there, means that we are going to have to have an absolute
perfect match. The incoming credentials have to be
that IP Address specifically. Now, if I were to
create this Trust, and then give it a --
oh, let's make this a really bad identity. Let's make it
associated with the PI User
called PI Admin. You know, this is, this is like a recipe
for how not to do Security, because
what this means is any joker sitting on this
computer, who's got a copy of, innocently enough
has a copy of DataLink, PI DataLink. Do you know DataLink
has the ability to write Values back to the PI Server?
So, if they are sitting there on a machine
that's got a Trust that's this liberal, then
at that point, they are going to have the ability to,
you know, do things to, to the Values on that Server
that you probably do not want just regular users to be able to do.
So, let's, you know, let's just say my --
let's call this myBetterTrust.
MyBetterTrust would be is if instead
of just making it completely liberal like this, we restrict
this and say, okay, we are going to only limit this to
the what was that?
It was called OPCpE.
It is case-sensitive in this
Application Name for the API-based Trust here.
So, that does a, it takes a huge
step in making this a better Trust because, now, only
that Application will be able to
write to it. Now, in this case, it's not allowing me to do
that because it already matches an existing Trust.
So, we do do a check for that to make sure you do not duplicate your
Trusts. Now, this is still not, you know, a,
a, the best Trust. Your best Trust
would be if you did
not associate this with such a powerful
user. PI Admin can on...can write not
just to, you know, the OPC Interface Tags,
it can write to anything. So, better would be
to associate this with an identity such as
this one I created. This identity is the only, is,
only has permission to write to certain OPC Interface Tags.
So, and again, if I try to save this, I will not be able to,
'cause I have already got a Trust that essentially has all that.