Peoplesoft
============================
https://docs.oracle.com/cd/E41633_01/pt853pbh1/eng/pt/tprt/concept_ApplicationServers-c071d0.html
https://docs.oracle.com/cd/E41633_01/pt853pbh1/eng/pt/tprt/concept_ApplicationServers-c071d0.html
Workstation listener (WSL)
The workstation listener monitors Oracle Tuxedo ports for initial connection requests sent from the PeopleTools development environment. After the workstation listener accepts a connection from a workstation, it directs the request to a workstation handler. From that point, the Microsoft Windows workstation interacts with the workstation handler to which it is assigned.
Workstation handler (WSH)
The workstation handler processes the requests that it receives from the workstation listener. A unique port number identifies a workstation handler. The port numbers for the workstation handler are selected (internally by Oracle Tuxedo) from a specified range of numbers. You can configure multiple workstation handlers to take care of demand increases; new processes are created as other processes become overloaded.
Oracle Jolt server listener (JSL)
The Oracle Jolt server listener applies only to browser requests. The Oracle Jolt server listener monitors the Oracle Jolt port for connection requests sent from the browser through the web server. After the Oracle Jolt server listener accepts a connection, it directs the request to an Oracle Jolt server handler. From that point, the browser interacts with the Oracle Jolt server handler. This is analogous to the relationship between the workstation server listener and workstation server handler.
Oracle Jolt server handler (JSH)
The Oracle Jolt server handler applies only to browser requests. The Oracle Jolt server handler processes the requests that it receives from the Oracle Java server listener. The port numbers for the Oracle Jolt server handler are selected internally by Oracle Tuxedo in sequential order.
Request queues
Each type of server process has a service request queue that it shares with other servers of the same type (as in PSAPPSRV on APPQ and PSQCKSRV on QCKQ). The workstation handler and Oracle Jolt server handler insert requests into the appropriate queue, and then the individual server processes complete each request in the order that it appears.
Server processes
The server processes act as the heart of the application server domain. They maintain the SQL connection and make sure that each transaction request gets processed on the database and that the results are returned to the appropriate origin.
PeopleSoft Server Processes
Multiple server processes run in an application server domain. A server process is executable code that receives incoming transaction requests. The server process carries out a request by making calls to a service, such as MgrGetObject.
Server processes invoke services to perform application logic and issue SQL to the RDBMS. Each application server process, such as PSAPPSRV, PSQCKSRV, PSQRYSRV, PSSAMSRV, or PSOPTENG, establishes and maintains its own connection to the database.
The server process waits for the service to finish, then returns information to the device that initiated the request, such as a browser. While a server process waits for a service to finish, other transaction requests wait in a queue until the current service finishes. A service may take a fraction of a second to finish or several seconds, depending on the type and complexity of the service. When the service finishes, the server process is then available to process the next request in the corresponding queue
You need to configure only those server processes that your implementation requires per domain. The minimum server processes that a domain requires are PSAPPSRV and PSSAMSRV.
You can configure multiple instances of the same server processes to start when you start the application server domain. This helps you handle predicted workloads. Furthermore, Oracle Tuxedo can dynamically generate incremental server processes to handle increasing numbers of transaction requests. The capability to configure multiple server processes and generate incremental server processes contributes to the application server's scalability.
The following list describes the possible server processes included in an application server domain. Depending on the configuration options that you choose, not all of the server processes will necessarily be a part of every domain.
•PSAPPSRV
This process performs functional requests, such as building and loading components (which were known as panel groups in previous releases). It also provides the memory and disk-caching feature for PeopleTools objects on the application server. PSAPPSRV is required to be running in any domain.
•PSQCKSRV
This process performs quick, read-only SQL requests. This is an optional process designed to improve performance by reducing the workload of PSAPPSRV.
•PSQRYSRV
This process is designed to handle any query run by PeopleSoft Query. This is an optional process designed to improve performance by reducing the workload of PSAPPSRV.
•PSSAMSRV
This SQL application manager process handles the conversational SQL that is mainly associated with PeopleSoft Application Designer. This process is required to be running on any domain.
•PSOPTENG
This optimization engine process provides optimization services in PeopleSoft Optimization Framework. You need to configure this process in a server domain only if you want to use the optimization plug-in delivered with PeopleSoft applications.
The following set of server processes is used for application messaging. (Your messaging domain must also contain PSAPPSRV and PSSAMSRV, the required server processes.)
•PSMSGDSP
•PSMSGHND
•PSPUBDSP
•PSPUBHND
•PSSUBDSP
•PSSUBHND
note:You can examine servers by using the ps -ef command in UNIX or Task Manager in Microsoft Windows. The PeopleSoft configuration utility, PSADMIN, also offers a monitoring utility.
Services
When a PeopleSoft application sends a request to the application server, it sends a service name and a set of parameters, such as MgrGetObject and its parameters. Oracle Tuxedo then queues the transaction request to a specific server process that is designed to handle certain services.
When a server process starts, it advertises to the system the predefined services it handles. You can see the association between the many services and server processes by reviewing the PSAPPSRV.UBB file.
Oracle Middleware
PeopleSoft software uses Oracle Tuxedo, a middleware framework and transaction monitor, to manage database transactions. PeopleSoft software also uses Oracle Jolt, a Java API and class library, as the layer that facilitates communication between the PeopleSoft servlets on the web server and the application server. Both Oracle Tuxedo and Jolt are required.
https://docs.oracle.com/cd/E15645_01/pt850pbr0/eng/psbooks/tsec/chapter.htm?File=tsec/htm/tsec03.htm
PeopleSoft Internet Architecture Security
PeopleSoft Internet Architecture security is also known as runtime security. Only authorized users can connect to the web and application server, and only authorized application servers can connect to a given database.
PeopleSoft software uses authentication tokens embedded in browser cookies to authorize users and enable single sign-in throughout the system. To secure links between elements of the system, including browsers, web servers, application servers, and database servers, PeopleSoft software incorporates a combination of SSL security and Oracle Tuxedo and Oracle Jolt encryption.
SSL is a protocol developed by Netscape that defines an interface for data encryption between network nodes. To establish an SSL-encrypted connection, the nodes must complete the SSL handshake. The simplified steps of the SSL handshake are as follows:
1 Client sends a request to connect.
2 Server responds to the connect request and sends a signed certificate.
3 Client verifies that the certificate signer is in its acceptable certificate authority list.
4 Client generates a session key to be used for encryption and sends it to the server encrypted with the server's public key (from the certificate received in step 2).
5 Server uses a private key to decrypt the client generated session key.
Establishing an SSL connection requires two certificates: one containing the public key of the server (server certificate or public key certificate) and another to verify the certification authority that issued the server certificate (trusted root certificate). The server needs to be configured to issue the server certificate when a client requests an SSL connection, and the client needs to be configured with the trusted root certificate of the certificate authority that issued the server certificate.
The nature of those configurations depends on both the protocol being used and the client and server platforms. In most cases you replace HTTP with LDAP. SSL is a lower level protocol than the application protocol, such as HTTP or LDAP. SSL works the same regardless of the application protocol.
Note. Establishing SSL connections with LDAP is not related to web server certificates or certificates used with PeopleSoft integrations
The system uses SSL encryption in the following locations:
Between the browser and the web server.
Between the application server and the integration gateway.
Between the integration gateway and an external system.
The system uses Oracle Tuxedo and Oracle Jolt encryption in these locations:
Between the web server and the application server.
Between the integration gateway and a PeopleSoft system (Oracle Jolt only).
Security between the application server and database is supplied by RDBMS connectivity.
PeopleSoft Integration Broker and portal products have additional security concerns, which are addressed in the documentation for those products.
PeopleSoft Authorization IDss
The PeopleSoft system uses various authorization IDs and passwords to control user access. You use PeopleTools Security to assign two of these IDs: the user ID and the symbolic ID.
This section discusses:
User IDs.
Connect ID.
Access IDs.
Symbolic IDs.
Administrator access.
User IDs
User id is nothing but peoplesoft user uses his id and password at peoplesoft login page. as peoplesoft DBA , you assign a user with user id and password
The system can also use a user id stored within an LDAP directory server.
what is connect id ?
Connect ID
The connect ID performs the initial connection to the database.
Note. PeopleSoft no longer creates users at the database level.
what is the use of connect ID?
if connect ID is used the you do not have to create a new database user for every PeopleSoft user that you add to the system.
why connected Id is required ?
Note. A connect ID is required for a direct connection (two-tier connection) to the database.
Application servers and two-tier Microsoft Windows clients require a connect ID.
You have to specify the connect ID for an application server in the Signon section of the PSADMIN utility.
For Microsoft Windows clients, you specify the connect ID in the Startup tab of PeopleSoft Configuration Manager.
You can create a connect ID by running the Connect.SQL and Grant.SQL scripts.
Note. When performing a database compare or copy, both databases must have the same connect ID.
Warning! Without a connect ID specified, the system assumes the workstation is accessing PeopleSoft through an application server. The option to override the database type is disabled.
Access IDs
When you create any user ID, you must assign it an access profile, which specifies an access ID and password.
The PeopleSoft access ID is the RDBMS ID with which PeopleSoft applications are ultimately connected to your database after the PeopleSoft system connects using the connect ID and validates the user ID and password. An access ID typically has all the RDBMS privileges necessary to access and manipulate data for an entire PeopleSoft application. The access ID should have Select, Update, and Delete access.
Users do not know their corresponding access IDs. They just sign in with their user IDs and passwords. Behind the scenes, the system signs them into the database using the access ID.
If users try to access the database directly with a query tool using their user or connect IDs, they have limited access. User and connect IDs only have access to the few PeopleSoft tables used during sign-in, and that access is Select-level only. Furthermore, PeopleSoft encrypts the sensitive data that resides in those tables.s
Note. Access profiles are used when an application server connects to the database, when a Microsoft Windows workstation connects directly to the database, and when a batch job connects directly to the database. Access profiles are not used when end users access applications through PeopleSoft Pure Internet Architecture. During a PeopleSoft Pure Internet Architecture transaction, the application server maintains a persistent connection to the database, and the end users leverage the access ID that the application server domain used to sign in to the database.
Note. PeopleSoft suggests that you only use one access ID for your system. Some RDBMS do not permit more than one database table owner. If you create more than one access ID, it may require further steps to ensure that this ID has the correct rights to all PeopleSoft system tables.
Symbolic IDs
PeopleSoft encrypts the access ID when it is stored in the PeopleTools security tables. Consequently, an encrypted value cannot be readily referenced or accessed. So when the access ID, which is stored in PSACCESSPRFL, must be retrieved or referenced, the query selects the appropriate access ID by using the symbolic ID as a search key.
The symbolic ID acts as an intermediary entity between the user ID and the access ID. All the user IDs are associated with a symbolic ID, which in turn is associated with an access ID. If you change the access ID, you need to update only the reference of the access ID to the symbolic ID in the PSACCESSPRFL table. You do not need to update every user profile in the PSOPRDEFN table.
Administrator Access
As an administrator, you must customize your own user definition. PeopleSoft delivers at least one full-access user ID with each delivered database. Your first task should be to sign in with this ID and personalize it for your needs or to create a new, full-access ID, being sure to specify a new password. You should change the passwords of all delivered IDs as soon as possible.
Note. PeopleSoft-delivered IDs and passwords are documented in your installation manual.
When you install PeopleSoft, you are prompted for an RDBMS system administrator ID and password. This information is used to automatically create a default access profile. If you will be using more than one access profile, set up the others before creating any new PeopleSoft security definitions. Most sites only use one access profile.
The number of database-level IDs you create is up to your site requirements. However, in most cases, having fewer database-level IDs reduces maintenance issues.
For example, if you implement pure LDAP authentication, at a minimum you need two database-level IDs—your access ID and your connect ID. With this scenario, in PeopleSoft you need to maintain only a symbolic ID to reference the access ID and maintain a user ID that the application server uses during sign-in. With this minimal approach, each user who needs a two-tier connection, to run an upgrade, for example, could use the same user ID that the application server uses.
PeopleSoft Sign-in :
This section discusses:
PeopleSoft sign-in.
Directory server integration.
Authentication and signon PeopleCode.
Single signon.
PeopleSoft Sign-in
The most common direct sign-in to the PeopleSoft database is the application server sign-in.
These are the basic steps that are taken when the application server signs in to the database:
1.Initial connection.
The application server starts and uses the connect ID and user ID specified in its configuration file (PSAPPSRV.CFG) to perform the initial connection to the database.
2.The server performs a SQL Select statement on security tables.
After the connect ID is verified, the application server performs a Select statement on PeopleTools security tables, such as PSOPRDEFN, PSACCESSPRFL, and PSSTATUS. From these tables, the application server gathers such items as the user ID and password, symbolic ID, access ID, and access password. After the application server has the required information, it disconnects.
3.The server reconnects using the access ID.
When the system verifies that the access ID is valid, the application server begins the persistent connection to the database that all PeopleSoft Pure Internet Architecture and Microsoft Windows three-tier clients use to access the database. Typically, the users signing in using a Microsoft Windows workstation are developers using PeopleSoft Application Designer.
Note. A Microsoft Windows workstation attempting a two-tier connection uses the same process as the application server.
PeopleSoft recommends that all connectivity be made through either a three-tier Microsoft Windows client or through the browser. A two-tier connection is no longer necessary other than for the application server, PeopleSoft Process Scheduler, or for a user who will be running upgrades or PeopleSoft Data Mover scripts.
Sign-in PeopleCode does not run during a two-tier connection, so maintaining two-tier users in an LDAP server is not supported.
Directory Server Integration
PeopleSoft recognizes that your site uses software produced by numerous vendors, and each different product requires security authorizations for users. Most of these products adhere to the model that includes user profiles and roles (or groups) to which users belong. PeopleSoft enables you to integrate your authentication scheme for the PeopleSoft system with your existing infrastructure. You can reuse user profiles and roles that are already defined within an LDAP directory service.
Organizations typically store user profiles in a central repository that serves user information for all of the programs that require it. The central repository is typically an LDAP directory server.
A directory server enables you to maintain a single, centralized user profile that you can use across all of your PeopleSoft and non-PeopleSoft applications. This approach reduces redundant maintenance of user information stored separately throughout your enterprise, and it reduces the possibility of user information getting out of synchronization.
You always maintain permission lists and roles using PeopleTools Security. However, you can maintain user profiles in PeopleTools Security or with an external LDAP server.
Authentication and Signon PeopleCode :
You can store PeopleSoft passwords within PeopleTools, in the PSOPRDEFN table. You can also store and maintain user passwords and the rest of the user profile data in an LDAP directory server. PeopleSoft retrieves the information stored in an external directory server using a combination of the User Profiles component interface and sign-in PeopleCode.
If you decide to reuse existing user profiles stored in a directory server, you don’t need to perform dual maintenance on the two copies of the user data—one copy in the LDAP server and one copy in PSOPRDEFN. PeopleSoft ensures that the user information stays synchronized. If you configure LDAP authentication, you maintain your user profiles in LDAP and not in PeopleTools Security.
Signon PeopleCode copies the most recent user profile data from a directory server to the local database whenever a user signs in. PeopleSoft applications reference the user information stored in the PeopleSoft database rather than making a call to the LDAP directory each time the system requires user profile information. Signon PeopleCode ensures the local database has a current copy of the user profile based on the information in the directory. Each time the user signs in, signon PeopleCode checks to see to see if the row in the user profile cache needs to be updated.
The sign-in process occurs as follows:
The user enters a user ID and password on the sign-in page.
PeopleTools attempts to authenticate the user against the PSOPRDEFN table.
Signon PeopleCode runs.
The default signon PeopleCode program updates the user profile based on the current data stored in the directory server.
You can use signon PeopleCode and business interlinks to synchronize the local copy of the user profile with any data source at sign-in time; the program that ships with PeopleTools is designed to synchronize the user profile with an LDAP directory server only. Because the sign-in program is PeopleCode, you can modify it, incorporating any of the PeopleSoft integration technologies that PeopleCode supports.
To edit the signon PeopleCode program, you open the LDAP function library record and use the PeopleCode editor to customize the PeopleCode. Developers who modify the sign-in PeopleCode program need to have a good understanding of PeopleCode and the integration features it offers.
Single Signon :
PeopleSoft Pure Internet Architecture uses browser cookies for seamless single signon across all PeopleSoft nodes. A node refers to a database and the application servers connected to it. For example, a user can complete a PeopleSoft Human Resources transaction, and then click a link for a PeopleSoft Financials transaction without ever reentering a password. Single signon is especially important to the PeopleSoft portal, which aggregates content from several different applications and data sources into a single, integrated display.
Process Scheduler Cache
Process scheduler has it’s own cache apart from the application server cache. It keeps its own copies of Component Interfaces,
Application Engine PeopleCode and Application engine sections and SQL.
In order to clear the Process Scheduler cache , the process scheduler needs to be shut down.
Component Interface
Application Engine People Code
Application Engine sections
SQL
To delete process scheduler cache, you need to manually delete all the files and folders
in this directory $PS_HOME/appserv/prcs/{YOUR-ENV-NAME}/cache on the process scheduler machine(s).
Application Engine
If you are having an issue with an application engine still running old code after a project migration then ask for a Process Scheduler cache clear.
The other 2 types of server cache DO NOT need to be cleared.
If your application engine calls a component interface and you recently migrated a change to the component interface, generally a Process Scheduler cache clear is needed. The other 2 types of server cache DO NOT need to be cleared.
COBOL
COBOL does not use CACHE. If you are having a COBOL issue cache has nothing to do with it. Do not waste your time trying.
SQR
SQR does not use CACHE. If you are having a SQR issue cache has nothing to do with it. Do not waste your time trying.
============================
https://docs.oracle.com/cd/E41633_01/pt853pbh1/eng/pt/tprt/concept_ApplicationServers-c071d0.html
https://docs.oracle.com/cd/E41633_01/pt853pbh1/eng/pt/tprt/concept_ApplicationServers-c071d0.html
Workstation listener (WSL)
The workstation listener monitors Oracle Tuxedo ports for initial connection requests sent from the PeopleTools development environment. After the workstation listener accepts a connection from a workstation, it directs the request to a workstation handler. From that point, the Microsoft Windows workstation interacts with the workstation handler to which it is assigned.
Workstation handler (WSH)
The workstation handler processes the requests that it receives from the workstation listener. A unique port number identifies a workstation handler. The port numbers for the workstation handler are selected (internally by Oracle Tuxedo) from a specified range of numbers. You can configure multiple workstation handlers to take care of demand increases; new processes are created as other processes become overloaded.
Oracle Jolt server listener (JSL)
The Oracle Jolt server listener applies only to browser requests. The Oracle Jolt server listener monitors the Oracle Jolt port for connection requests sent from the browser through the web server. After the Oracle Jolt server listener accepts a connection, it directs the request to an Oracle Jolt server handler. From that point, the browser interacts with the Oracle Jolt server handler. This is analogous to the relationship between the workstation server listener and workstation server handler.
Oracle Jolt server handler (JSH)
The Oracle Jolt server handler applies only to browser requests. The Oracle Jolt server handler processes the requests that it receives from the Oracle Java server listener. The port numbers for the Oracle Jolt server handler are selected internally by Oracle Tuxedo in sequential order.
Request queues
Each type of server process has a service request queue that it shares with other servers of the same type (as in PSAPPSRV on APPQ and PSQCKSRV on QCKQ). The workstation handler and Oracle Jolt server handler insert requests into the appropriate queue, and then the individual server processes complete each request in the order that it appears.
Server processes
The server processes act as the heart of the application server domain. They maintain the SQL connection and make sure that each transaction request gets processed on the database and that the results are returned to the appropriate origin.
PeopleSoft Server Processes
Multiple server processes run in an application server domain. A server process is executable code that receives incoming transaction requests. The server process carries out a request by making calls to a service, such as MgrGetObject.
Server processes invoke services to perform application logic and issue SQL to the RDBMS. Each application server process, such as PSAPPSRV, PSQCKSRV, PSQRYSRV, PSSAMSRV, or PSOPTENG, establishes and maintains its own connection to the database.
The server process waits for the service to finish, then returns information to the device that initiated the request, such as a browser. While a server process waits for a service to finish, other transaction requests wait in a queue until the current service finishes. A service may take a fraction of a second to finish or several seconds, depending on the type and complexity of the service. When the service finishes, the server process is then available to process the next request in the corresponding queue
You need to configure only those server processes that your implementation requires per domain. The minimum server processes that a domain requires are PSAPPSRV and PSSAMSRV.
You can configure multiple instances of the same server processes to start when you start the application server domain. This helps you handle predicted workloads. Furthermore, Oracle Tuxedo can dynamically generate incremental server processes to handle increasing numbers of transaction requests. The capability to configure multiple server processes and generate incremental server processes contributes to the application server's scalability.
The following list describes the possible server processes included in an application server domain. Depending on the configuration options that you choose, not all of the server processes will necessarily be a part of every domain.
•PSAPPSRV
This process performs functional requests, such as building and loading components (which were known as panel groups in previous releases). It also provides the memory and disk-caching feature for PeopleTools objects on the application server. PSAPPSRV is required to be running in any domain.
•PSQCKSRV
This process performs quick, read-only SQL requests. This is an optional process designed to improve performance by reducing the workload of PSAPPSRV.
•PSQRYSRV
This process is designed to handle any query run by PeopleSoft Query. This is an optional process designed to improve performance by reducing the workload of PSAPPSRV.
•PSSAMSRV
This SQL application manager process handles the conversational SQL that is mainly associated with PeopleSoft Application Designer. This process is required to be running on any domain.
•PSOPTENG
This optimization engine process provides optimization services in PeopleSoft Optimization Framework. You need to configure this process in a server domain only if you want to use the optimization plug-in delivered with PeopleSoft applications.
The following set of server processes is used for application messaging. (Your messaging domain must also contain PSAPPSRV and PSSAMSRV, the required server processes.)
•PSMSGDSP
•PSMSGHND
•PSPUBDSP
•PSPUBHND
•PSSUBDSP
•PSSUBHND
note:You can examine servers by using the ps -ef command in UNIX or Task Manager in Microsoft Windows. The PeopleSoft configuration utility, PSADMIN, also offers a monitoring utility.
Services
When a PeopleSoft application sends a request to the application server, it sends a service name and a set of parameters, such as MgrGetObject and its parameters. Oracle Tuxedo then queues the transaction request to a specific server process that is designed to handle certain services.
When a server process starts, it advertises to the system the predefined services it handles. You can see the association between the many services and server processes by reviewing the PSAPPSRV.UBB file.
Oracle Middleware
PeopleSoft software uses Oracle Tuxedo, a middleware framework and transaction monitor, to manage database transactions. PeopleSoft software also uses Oracle Jolt, a Java API and class library, as the layer that facilitates communication between the PeopleSoft servlets on the web server and the application server. Both Oracle Tuxedo and Jolt are required.
https://docs.oracle.com/cd/E15645_01/pt850pbr0/eng/psbooks/tsec/chapter.htm?File=tsec/htm/tsec03.htm
PeopleSoft Internet Architecture Security
PeopleSoft Internet Architecture security is also known as runtime security. Only authorized users can connect to the web and application server, and only authorized application servers can connect to a given database.
PeopleSoft software uses authentication tokens embedded in browser cookies to authorize users and enable single sign-in throughout the system. To secure links between elements of the system, including browsers, web servers, application servers, and database servers, PeopleSoft software incorporates a combination of SSL security and Oracle Tuxedo and Oracle Jolt encryption.
SSL is a protocol developed by Netscape that defines an interface for data encryption between network nodes. To establish an SSL-encrypted connection, the nodes must complete the SSL handshake. The simplified steps of the SSL handshake are as follows:
1 Client sends a request to connect.
2 Server responds to the connect request and sends a signed certificate.
3 Client verifies that the certificate signer is in its acceptable certificate authority list.
4 Client generates a session key to be used for encryption and sends it to the server encrypted with the server's public key (from the certificate received in step 2).
5 Server uses a private key to decrypt the client generated session key.
Establishing an SSL connection requires two certificates: one containing the public key of the server (server certificate or public key certificate) and another to verify the certification authority that issued the server certificate (trusted root certificate). The server needs to be configured to issue the server certificate when a client requests an SSL connection, and the client needs to be configured with the trusted root certificate of the certificate authority that issued the server certificate.
The nature of those configurations depends on both the protocol being used and the client and server platforms. In most cases you replace HTTP with LDAP. SSL is a lower level protocol than the application protocol, such as HTTP or LDAP. SSL works the same regardless of the application protocol.
Note. Establishing SSL connections with LDAP is not related to web server certificates or certificates used with PeopleSoft integrations
The system uses SSL encryption in the following locations:
Between the browser and the web server.
Between the application server and the integration gateway.
Between the integration gateway and an external system.
The system uses Oracle Tuxedo and Oracle Jolt encryption in these locations:
Between the web server and the application server.
Between the integration gateway and a PeopleSoft system (Oracle Jolt only).
Security between the application server and database is supplied by RDBMS connectivity.
PeopleSoft Integration Broker and portal products have additional security concerns, which are addressed in the documentation for those products.
PeopleSoft Authorization IDss
The PeopleSoft system uses various authorization IDs and passwords to control user access. You use PeopleTools Security to assign two of these IDs: the user ID and the symbolic ID.
This section discusses:
User IDs.
Connect ID.
Access IDs.
Symbolic IDs.
Administrator access.
User IDs
User id is nothing but peoplesoft user uses his id and password at peoplesoft login page. as peoplesoft DBA , you assign a user with user id and password
The system can also use a user id stored within an LDAP directory server.
what is connect id ?
Connect ID
The connect ID performs the initial connection to the database.
Note. PeopleSoft no longer creates users at the database level.
what is the use of connect ID?
if connect ID is used the you do not have to create a new database user for every PeopleSoft user that you add to the system.
why connected Id is required ?
Note. A connect ID is required for a direct connection (two-tier connection) to the database.
Application servers and two-tier Microsoft Windows clients require a connect ID.
You have to specify the connect ID for an application server in the Signon section of the PSADMIN utility.
For Microsoft Windows clients, you specify the connect ID in the Startup tab of PeopleSoft Configuration Manager.
You can create a connect ID by running the Connect.SQL and Grant.SQL scripts.
Note. When performing a database compare or copy, both databases must have the same connect ID.
Warning! Without a connect ID specified, the system assumes the workstation is accessing PeopleSoft through an application server. The option to override the database type is disabled.
Access IDs
When you create any user ID, you must assign it an access profile, which specifies an access ID and password.
The PeopleSoft access ID is the RDBMS ID with which PeopleSoft applications are ultimately connected to your database after the PeopleSoft system connects using the connect ID and validates the user ID and password. An access ID typically has all the RDBMS privileges necessary to access and manipulate data for an entire PeopleSoft application. The access ID should have Select, Update, and Delete access.
Users do not know their corresponding access IDs. They just sign in with their user IDs and passwords. Behind the scenes, the system signs them into the database using the access ID.
If users try to access the database directly with a query tool using their user or connect IDs, they have limited access. User and connect IDs only have access to the few PeopleSoft tables used during sign-in, and that access is Select-level only. Furthermore, PeopleSoft encrypts the sensitive data that resides in those tables.s
Note. Access profiles are used when an application server connects to the database, when a Microsoft Windows workstation connects directly to the database, and when a batch job connects directly to the database. Access profiles are not used when end users access applications through PeopleSoft Pure Internet Architecture. During a PeopleSoft Pure Internet Architecture transaction, the application server maintains a persistent connection to the database, and the end users leverage the access ID that the application server domain used to sign in to the database.
Note. PeopleSoft suggests that you only use one access ID for your system. Some RDBMS do not permit more than one database table owner. If you create more than one access ID, it may require further steps to ensure that this ID has the correct rights to all PeopleSoft system tables.
Symbolic IDs
PeopleSoft encrypts the access ID when it is stored in the PeopleTools security tables. Consequently, an encrypted value cannot be readily referenced or accessed. So when the access ID, which is stored in PSACCESSPRFL, must be retrieved or referenced, the query selects the appropriate access ID by using the symbolic ID as a search key.
The symbolic ID acts as an intermediary entity between the user ID and the access ID. All the user IDs are associated with a symbolic ID, which in turn is associated with an access ID. If you change the access ID, you need to update only the reference of the access ID to the symbolic ID in the PSACCESSPRFL table. You do not need to update every user profile in the PSOPRDEFN table.
Administrator Access
As an administrator, you must customize your own user definition. PeopleSoft delivers at least one full-access user ID with each delivered database. Your first task should be to sign in with this ID and personalize it for your needs or to create a new, full-access ID, being sure to specify a new password. You should change the passwords of all delivered IDs as soon as possible.
Note. PeopleSoft-delivered IDs and passwords are documented in your installation manual.
When you install PeopleSoft, you are prompted for an RDBMS system administrator ID and password. This information is used to automatically create a default access profile. If you will be using more than one access profile, set up the others before creating any new PeopleSoft security definitions. Most sites only use one access profile.
The number of database-level IDs you create is up to your site requirements. However, in most cases, having fewer database-level IDs reduces maintenance issues.
For example, if you implement pure LDAP authentication, at a minimum you need two database-level IDs—your access ID and your connect ID. With this scenario, in PeopleSoft you need to maintain only a symbolic ID to reference the access ID and maintain a user ID that the application server uses during sign-in. With this minimal approach, each user who needs a two-tier connection, to run an upgrade, for example, could use the same user ID that the application server uses.
PeopleSoft Sign-in :
This section discusses:
PeopleSoft sign-in.
Directory server integration.
Authentication and signon PeopleCode.
Single signon.
PeopleSoft Sign-in
The most common direct sign-in to the PeopleSoft database is the application server sign-in.
These are the basic steps that are taken when the application server signs in to the database:
1.Initial connection.
The application server starts and uses the connect ID and user ID specified in its configuration file (PSAPPSRV.CFG) to perform the initial connection to the database.
2.The server performs a SQL Select statement on security tables.
After the connect ID is verified, the application server performs a Select statement on PeopleTools security tables, such as PSOPRDEFN, PSACCESSPRFL, and PSSTATUS. From these tables, the application server gathers such items as the user ID and password, symbolic ID, access ID, and access password. After the application server has the required information, it disconnects.
3.The server reconnects using the access ID.
When the system verifies that the access ID is valid, the application server begins the persistent connection to the database that all PeopleSoft Pure Internet Architecture and Microsoft Windows three-tier clients use to access the database. Typically, the users signing in using a Microsoft Windows workstation are developers using PeopleSoft Application Designer.
Note. A Microsoft Windows workstation attempting a two-tier connection uses the same process as the application server.
PeopleSoft recommends that all connectivity be made through either a three-tier Microsoft Windows client or through the browser. A two-tier connection is no longer necessary other than for the application server, PeopleSoft Process Scheduler, or for a user who will be running upgrades or PeopleSoft Data Mover scripts.
Sign-in PeopleCode does not run during a two-tier connection, so maintaining two-tier users in an LDAP server is not supported.
Directory Server Integration
PeopleSoft recognizes that your site uses software produced by numerous vendors, and each different product requires security authorizations for users. Most of these products adhere to the model that includes user profiles and roles (or groups) to which users belong. PeopleSoft enables you to integrate your authentication scheme for the PeopleSoft system with your existing infrastructure. You can reuse user profiles and roles that are already defined within an LDAP directory service.
Organizations typically store user profiles in a central repository that serves user information for all of the programs that require it. The central repository is typically an LDAP directory server.
A directory server enables you to maintain a single, centralized user profile that you can use across all of your PeopleSoft and non-PeopleSoft applications. This approach reduces redundant maintenance of user information stored separately throughout your enterprise, and it reduces the possibility of user information getting out of synchronization.
You always maintain permission lists and roles using PeopleTools Security. However, you can maintain user profiles in PeopleTools Security or with an external LDAP server.
Authentication and Signon PeopleCode :
You can store PeopleSoft passwords within PeopleTools, in the PSOPRDEFN table. You can also store and maintain user passwords and the rest of the user profile data in an LDAP directory server. PeopleSoft retrieves the information stored in an external directory server using a combination of the User Profiles component interface and sign-in PeopleCode.
If you decide to reuse existing user profiles stored in a directory server, you don’t need to perform dual maintenance on the two copies of the user data—one copy in the LDAP server and one copy in PSOPRDEFN. PeopleSoft ensures that the user information stays synchronized. If you configure LDAP authentication, you maintain your user profiles in LDAP and not in PeopleTools Security.
Signon PeopleCode copies the most recent user profile data from a directory server to the local database whenever a user signs in. PeopleSoft applications reference the user information stored in the PeopleSoft database rather than making a call to the LDAP directory each time the system requires user profile information. Signon PeopleCode ensures the local database has a current copy of the user profile based on the information in the directory. Each time the user signs in, signon PeopleCode checks to see to see if the row in the user profile cache needs to be updated.
The sign-in process occurs as follows:
The user enters a user ID and password on the sign-in page.
PeopleTools attempts to authenticate the user against the PSOPRDEFN table.
Signon PeopleCode runs.
The default signon PeopleCode program updates the user profile based on the current data stored in the directory server.
You can use signon PeopleCode and business interlinks to synchronize the local copy of the user profile with any data source at sign-in time; the program that ships with PeopleTools is designed to synchronize the user profile with an LDAP directory server only. Because the sign-in program is PeopleCode, you can modify it, incorporating any of the PeopleSoft integration technologies that PeopleCode supports.
To edit the signon PeopleCode program, you open the LDAP function library record and use the PeopleCode editor to customize the PeopleCode. Developers who modify the sign-in PeopleCode program need to have a good understanding of PeopleCode and the integration features it offers.
Single Signon :
PeopleSoft Pure Internet Architecture uses browser cookies for seamless single signon across all PeopleSoft nodes. A node refers to a database and the application servers connected to it. For example, a user can complete a PeopleSoft Human Resources transaction, and then click a link for a PeopleSoft Financials transaction without ever reentering a password. Single signon is especially important to the PeopleSoft portal, which aggregates content from several different applications and data sources into a single, integrated display.
Process Scheduler Cache
Process scheduler has it’s own cache apart from the application server cache. It keeps its own copies of Component Interfaces,
Application Engine PeopleCode and Application engine sections and SQL.
In order to clear the Process Scheduler cache , the process scheduler needs to be shut down.
Component Interface
Application Engine People Code
Application Engine sections
SQL
To delete process scheduler cache, you need to manually delete all the files and folders
in this directory $PS_HOME/appserv/prcs/{YOUR-ENV-NAME}/cache on the process scheduler machine(s).
Application Engine
If you are having an issue with an application engine still running old code after a project migration then ask for a Process Scheduler cache clear.
The other 2 types of server cache DO NOT need to be cleared.
If your application engine calls a component interface and you recently migrated a change to the component interface, generally a Process Scheduler cache clear is needed. The other 2 types of server cache DO NOT need to be cleared.
COBOL
COBOL does not use CACHE. If you are having a COBOL issue cache has nothing to do with it. Do not waste your time trying.
SQR
SQR does not use CACHE. If you are having a SQR issue cache has nothing to do with it. Do not waste your time trying.
No comments:
Post a Comment