Pro/User Data Management Committee White Paper
Pro/PDM 3.0 Data Security
A site needs to be able to restrict access to the data stored
on a PDM server.
Today, there are three easy ways that data can be not only
read by unauthorized users; but it can be modified or even
- A user who has root access to a pdm server can modify
it's pdmservers.txt file to include other PDM servers of
other sites. Root can switch-user to any other userid
which has manager access to databases on the other
servers. When PDM is started, the user can gain manager
access to the data on the other server. The other site
has no way to prevent this unauthorized access.
- Any user that has root access to a workstation on the AMP
network could install the PDM client software locally on
the machine. He could then modify the pdmservers.txt file
on the workstation to include any PDM server on the AMP
network. Again, root can switch-user to any userid and
gain unauthorized access to any data stored in PDM at
- Any user with root access to an authorized client of a
PDM server could create a local account as a userid which
has manager access to a PDM database on the local server.
As this other user, unauthorized access to the local
server can be obtained.
There is no effective way to prevent unauthorized access to
data stored in Pro/PDM 3.0.
Maintain a list which can be used to grant access for a userid
for a specific hostname. The list would contain three fields for
each userid@hostname level_of_access Asterisks, "*",
could be placed in either of the first two fields to allow
wildcards. This would allow a site the flexibility to restrict or
open up access to their databases. When the connection is
attempted to be made to the PDM server by a client, the user's
userid and hostname are checked against the list. The
level_of_access should be broken down into at least 3 levels:
- normal user
- database administrator
- software administrator
If the level of access allows, that user could inform the
Pro/PDM software that he would like his actions performed as a
database (not software) administrator and perform
"privileged tasks". This should be a toggle switch. A
scheme to remind the user that they are operating as an
administrator would be very useful, even if it was a code
appended to the window banner.
A database administrator should be allowed to create and
rename product databases, but should not be allowed to change the
software configuration (dbpaths, etc) or modify the admin
database. These tasks would be restricted to software
In addition, Pro/PDM should allow userid/password entry to be
required on application startup to gain access to a server. This
means that if a site wants to turn this option off, Pro/PDM would
not require the user to login. However, if a site is concerned
about the data security, this option could be enabled.
The proposed solution is only one way to solve the problems
listed above. There are other solutions which would be acceptable
as long as the problems indicated above would be corrected.
Below are some other priciples that should be considered:
- The security in Pro/PDM should be optional. If a
particular customer requires no or little security, they
should be able to install with the security level
- Security by application login (userid and password) is
the preferred method of security.
- Never send the authenication information (userid and
password) by clear text. It should be encrypted.
- The authentication security should not be the machine id
alone. It should be by userid. Security by machine id can
be an administrative nightmare.
- It is desirable for the authentication server to maintain
the context, i.e., there is no need to login repeatedly
for multiple applications during a session.
- Use an industry standard for the authentication method.
- OSF RPC (DCE) based on Kerberos from MIT.
- Microsoft RPC.
- RSA Public Key Security.
- NOTE: OEC RPC should not be used because of its
lack of security.
- Most of the more popular commercial databases can use one
of the industry standard authentication methods.
- Authentication is proving you are who you say you are. In
a network context, this means that clients and servers
must verify their identities before any requests are
processed. Strong authentication of users and network
applications protects against network spoofing.
- After a server has authenticated it's client, the server
needs to determine the resources to which the client has
access. This authorization service is provided in the
application server. The authentication mechanism
guarantees a user's identity but the authorization
service is responsible for determining which portions of
an application or its data is available to that user.
- Data Integrity
- Data integrity is a mechanism to determine whether a
message arrived intact and unaltered. This may be an
encrypted checksum of the packet. Data integrity degrades
the performance somewhat but has less overhead than full
- Data Privacy
- Data privacy hides the contents of messages from possible
eavesdroppers. The method for achieving data privacy is
most often encryption. There is a performance penalty for
using data privacy.
- Scrambling data in such a way that it isn't readable. To
read teh data again, the data must be unscrambled
- The object that is used while encrypting and decrypting
data. If you know the key, then you can decrypt an
encrypted message. The key is usually a 64-128 bit
- A ticket is your network identity. After you're
authenticated, the network security service will issue
the ticket. By giving the ticket to other network
services, you can securely present your network
credentials without logging in again. The servers are
guaranteed that you are presenting the correct identity
because the ticket originated from the security server.
Jeff Brent, Amp Incorporated - email@example.com