Tip:
Highlight text to annotate it
X
PI Trust Authentication.
In this section we discuss PI Trusts, but
let's discuss exactly what it is we will discuss
about PI Trusts. Two things, two important points:
we are first going to discuss what it's used for;
and then a completely separate issue, we are going to discuss how
it works, in other words, how you configure these
PI Trusts. Let's start with what it's used for.
For that I would like to go back to a display
that we saw earlier, a slide earlier, that showed the overall
architecture of the IT Monitor Server. Now,
there's two types of connections I would like to discuss,
two purposes what it's used for. There's
connections from applications that are unattended,
such as interfaces. And there's connections that come
from clients, and connections that
require a kind of a single sign-on leveraging
the Microsoft Windows
username and password. So let's talk about the
first one. Data Acquisition Nodes are unattended
applications. They are -- excuse me -- interfaces that
run on Data Acquisition Nodes are unattended applications.
It's an application that can start any time of the day or night.
If you need to reboot a, a computer
because of a power failure, when that starts up again you do not
want to require some kind of a user intervention.
That unattended application needs
to be able to connect to this server based
on some kind of criteria that's defined on the server.
We use a Trust to define that criteria.
Now, the second use of this is when you
have a connection coming from a PI client such
as ProcessBook or DataLink, and you would like that PI client
to make use of the same Windows username
and password that the user used to log in that
morning on his computer. You know, those folks want a
single sign-on behavior,
and PI Trusts are currently the only
way that we can implement this single sign-on behavior.
So you are going to notice in the, in the
slides that follow we are going to be discussing
the two different purposes of this. The
two different purposes, one being the
connection to the interfaces, and the other being
implementing the single sign-on. And I will try to make sure we distinguish
when we are talking about one vs the other.
Let's turn out attention now to how the Trust
mechanism actually works. You will notice that,
well, we describe it this way. The Trust associates
credentials, certain credentials,
and they are all listed here, to a specific
PI User. Now, the
credentials are what we would call connection credentials.
We derive these from the connection application,
and the ones I have just underlined here -- there are five
of them: the IP Address, the Machine Name, the
name of the application that's being run on the connecting client,
the Windows domain name and the Windows Username.
Those are the connecting credentials
that we can derive from a connecting client.
The Trust will simply map those, or associate
those credentials to a
specific PI User. Now, we can
map a single credential like, for
example, IP Address, and that's all that's required.
Or we can make a more restrictive Trust and let's
say that we require all these things to match
in order for us to grant a Trust.
It's you as the manager
who can decide how liberal
or restrictive a specific Trust
is. So, I said you can make the Trust
just require any one of these credentials, or
all of the credentials if your like, or any
combination thereof. Now,
before we go much further, I should just show you
example of Trusts. Here's an
example of a Trust. This is a very restrictive one.
This particular Trust has
a name, myRestrictiveTrust, and
I have specified in this Trust just about
everything it's possible to specify. As you can see,
we are specifying the Host Name, that's the computer name
as known by TCPIP; the IP Address,
and a corresponding NetMask,
which I will discuss later; I have also specified the
Domain, and the Windows Domain and
the Windows Username; and I have also specified the
name of the application, in this case ProcessBook. Now,
if a connecting client manages to
match all of these connection credentials -- in other
words, if we derive an exact match
on each one of these connection credentials -- it's coming from the right
computer, the right IP Address, the right domain, the right
user is logged in, etc. -- then we will grant
that user the same privileges as pidemo.
That's the PI User that we will associate with this,
with this particular Trust. Now that's
an example of a Restrictive Trust.
Here's an example of a less restrictive Trust.
This is a Trust that simply requires a match
in the computer name, and if we
get a match in the computer name, then we will simply associate
that particular connecting client with this user.
So, two quick examples of Trusts,
and we will see more later on.
These Trusts have to be implemented
when you are installing a distributed architecture,
when you are using a distributed architecture, and
to remind you of what that distributed architecture
is, let me go back to a previous slide. By
distributed architecture, again, we are talking about Data
Acquisition Nodes that are collecting
data using interfaces. Those require
a Trust to be able to connect here, namely,
and mainly the, the reason they have to have that
Trust is because it's an unattended application. These
interfaces can start 24 hours a day, and we
need some mechanism to allow them to connect properly
without the need for user interaction. I always found
it useful when learning a new topic
like this, to try to pretend I was the
computer. What's the computer going to be doing? Let's look at,
in detail, what's going to happen. Let's say that you have got a client
application like an interface that is trying to connect to this server,
or, it could be a client application like
ProcessBook or DataLink trying to connect to this server.
If that's the case, here's the procedure that you are
going to notice. This -- first of all, the PI Server is
going to derive a set of connection credentials from the connecting
process, from that connecting client. You notice
we are always careful to mention that we derive a set of
connection credentials. We do not say that the
client sends connection credentials 'cause technically it's the,
you know, it's an interaction between the operating system and our
software. We are deriving these connection credentials.
So, one way or another, we get these
connection credentials. If those credentials
match the attributes that are defined in the Trust,
then the process gets the privileges of that PI's... PIUser.
Now, there's an important word here I should highlight.
If the credentials match all the
attributes. Now that means, as I mentioned earlier, if you
have a very narrowly-defined Trust
that has lots of criteria that need to be met,
then, of course, it's going to be less likely
that, that the wrong connecting
client accidentally gets associated with the,
with a PIUser that it should not.
So, you can make that Trust as restrictive as you
need to because we do need to match all the
criteria that are defined in the Trust. Here's an
example of a Trust; in this case, a very, very simple Trust.
The Trust name is simply called myTrust1.
The name is completely arbitrary. The IP
Host, that's the computer name, is that
full, full
name, not just the local name but the fully-qualified
domain name. And,
finally, the PIUser that we will associate with this is
piadmin. So, what we are saying here is, because
this Trust exists, and it exists on the PIServer,
if we have a computer anywhere in the
world, really, that has that name, and it attempts to connect
using a PI connection, we are going to grant it the same privileges
as piadmin.
I would like to make one more point about this Trust. Now, let's say that
you have got a user that is connecting to this server
but he happens to match two separate
Trust definitions. There's one Trust definition,
and he matches that, say, because of the IP
Address he's coming from. But then, there's a separate one
and he matches that based on his Windows username and password.
Well, as you can see, if you look at our
documentation on this in our System
Management Guide -- this is in the Server Document Set --
there is a kind of a Scoring Table.
Now, here it is. This Scoring Table
ranks the different
connection criteria -- these connection credentials, I should say --
as to which one ranks higher. So what we do is we
add up all those things in which we match on a Trust
and then whichever one has the higher score, that's the
Trust that is granted.
There's an alternate way that we can describe this. Let's,
let's pretend that we have got a connecting client here that's either
an interface or a copy of ProcessBook or DataLink,
and we are trying to get to the PI Server.
All those connections are going to be handled
by the PINetMGR subsystem. That's a service that runs on the
PI Server. The first test is whether
we pass through the PIFireWall.
In other words, is any
of the connecting client's attributes like it's Node
Name or its IP Address -- are any of those attributes
dis-allowed by the definitions
in the PIFireWall? So, typically, the PIFireWall
is allowing all incoming connections, so unless you have
explicitly defined the certain
entries in the Firewall Table to disallow certain IP
Addresses or Node Names, then this test should work just fine.
Now at that point there's, there's two paths we can go on. Let's
take a look at the non-interactive login first. This is a
login that's being done by a non-interactive
process. In other words, one that cannot respond to a
username and password prompt. This would be an interface, for example.
We derive connection credentials
from that connecting client on the
PIServer, and we compare those connection credentials
against this PI Trust Table. If we
match what's in the PI Trust Table,
if the connecting credentials match, then we will
associate that client with a specific
PIUser that's defined in the Trust
entry. We check to see who that user is
and what groups he belongs to, and then we go ahead
and try to make this connection. And depending on what the
privileges are of the user that's been defined in the
Trust Table, depending on what his privileges are,
and the privileges of the groups he belongs to, then we will
either grant or not grant access to the database.
Now that's
completely different path than what you'd seen down here if you
are connecting as a copy of ProcessBook.
The copy of ProcessBook, that's an interactive login.
Copy of ProcessBook, we are not going to be using the PI Trust
Table. We are instead simply going to be
waiting for the user to pass a username and password.
Now that can be automated in our Client Tools so that we, we
pass a user and password without user interaction, or it can,
it can be in reaction to a -- or in response to
a connection dialog prompt. So,
interactive logins do not go through the PI
Trust authentication. We simply
provide username and password, and then
based on who the user is and what groups he belongs to, we will give
him access based on that criteria. There's one
more situation in which you may define a Trust,
and that is when you want a user over here to be able to
get access to this using simply his Windows username
and password. That would be the kind of
a single sign-on behavior that a lot of customers would like.
The way you do this is you take whatever
connection criteria that this user would be
using to log onto Windows, his Windows username or his
domain name, for example. And, you build
a Trust that says that everybody who has
those connection criteria, that Windows username or
that domain, or both the domain and the username --
you, you build a Trust so that everybody
who connects using those credentials will be granted
a, a Trust and associated
with a PIUser who has permissions to connect.
So, when the user logs in in the morning,
when he then tries to connect to PI, we will determine
that he is a user that matches that Trust
and then we will associate him with a PIUser who has
permission to go through this test and make it to the PI
Database.