LinkedIn
Copied!

Table of Contents

Service package access group

Learn about the differences between configuring a service package access group for an authenticated user and unauthenticated user. Review the following information so you can decide which configuration applies to your business needs before completing the Context tab of your service package.

For more information, see Defining processing and authentication for service packages.

Example of unauthenticated user's service package access group

If your service is to execute without authentication, set up an access group that provides only the minimum capabilities to service requestors and reference the access group in the Service access group field on the service package rule form. For example, you can include an access role (Rule-Access-Role-Name rule type) linked to Access of Role to Object rules (Rule-Access-Role-Obj rule type) that limits which classes the service can view or update. Also, review the service activity to ensure that no combination of input parameters allows the activity to perform more than the service needs.

Example of authenticated user's access group

The access group in the service package is used to find the service rules, and the service activities to be run must be accessible to requestors operating with this access group. This requires the authentication activity to be accessible to the access group specified in the service package. If authenticated, the access group of the authenticated operator is used as the context, rather than the access group of the service package, in order to find all application-specific rules. That context is reset if the service is pooled and the requestor is returned to the pool. When you select Requires authentication on the service package rule form, authentication occurs only for the first request for stateful services that use pooling and do not destroy the requestor. Later service requests that include the Session ID in the request message continue with the same previously authenticated requestor session.

In high-volume production settings, authentication can be costly in terms of computer resources. However, unauthenticated service requestors can access the rulesets and versions conveyed by the access group in the Service access group field plus those assigned to the requestor type named APP. (Services run as APP requestors.) Depending on security and volume factors, for best performance, you can leave the Requires authentication box cleared.

Service operator IDs and passwords

The location and name of the operator ID and password values vary, depending on the service type:

Service type Password configuration
Email The operator ID and password are on the Properties tab in the Requestor login section of the email listener.

For more information, see Configuring email listener routing.

JMS The operator ID and password are on the Listener Properties tab in the Requestor login section of the JMS listener data instance.

For more information, see JMS Listener form - Completing the Listener Properties tab.

MQ The operator ID and password are on the Listener Properties tab in the Requestor login section of the MQ listener data instance.

For more information, see MQ Listener form - Completing the Listener Properties tab.

SOAP, SAP The arriving SOAP request message must contain a user name and password value either in the HTTP header (using HTTP Basic Authentication), or as header or parameter values of the SOAP request envelope.

For more information, see Configuring the request for a SOAP connector and SAP Connector form - Completing the Request tab.

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.