Understanding QAS Security

This section discusses QAS security flow.

PeopleSoft Query uses query access group trees to control security of the tables in your PeopleSoft database. You define a hierarchy of record components, based on logical or functional groupings, and then give users access to one or more branches of the tree. Users can use PeopleSoft Query to retrieve information only from record definitions they have access to based on the query access tree assignment.

QAS service operations are delivered with User/Password Required enabled andWS Security Req Verification set to Encrypt and Digitally Sign or HTTPS..

Client applications using QAS service operations must either digitally encrypt and sign the request or send the request over HTTPS.

Service operations are secured by means of permission lists. PeopleSoft applications deliver the permission list PTPT2200 (QAS access), which has full access to all QAS service operations and the application engine program QASEXEQRY. The role QAS Admin contains the permission list PTPT2200. Any users assigned the role QAS Admin can access the QAS service operations.

Web services security (WS-Security) is implemented on the integration gateway for inbound and outbound integrations with third-party systems. QAS service operations use WS-Security.

See Web Services Overview.

The service operation QAS_EXECUTEQRY_SYNCPOLL_OPER schedules the application engine program QASEXEQRY to run in Process Scheduler, therefore the user initiating the request must have permission to run QASEXEQRY in the Process Profile.

See QAS_EXECUTEQRYSYNCPOLL_OPER.

Image: QAS request from a third-party security flow

This diagram illustrates the QAS request inbound flow from a third-party system in the Integration Broker

QAS request from a third-party security flow

When any transaction arrives at the integration gateway, the PeopleSoft system checks for the existence of a WS-Security SOAP header. If it exists, the integration gateway validates the digital signature if it exists, and decrypts the UsernameToken and optional password to restore the user ID information to clear text format. The integration gateway then passes the user ID information, and UsernameToken password if provided by the sender, to the application server, where additional security processing is performed.

If a user name and password are supplied in the SOAP header, the user is validated in the PeopleSoft system.

If no user ID and password are supplied, the request is rejected.

The PeopleSoft system then validates whether the user's permission list grants access to the QAS service operation.

If the user is authorized to the service operation, then Query Access security is used and the request is processed.