About Operator ID data instances
About Organization Units
More about Authentication Services
|
|
You can configure your PRPC system to authenticate users in one of several ways:
The publication Authentication in PegaRULES Process Commander, a document available on the PDN, provides an in-depth description of how authentication works, including how PRPC interacts with external authentication implementations. This document also provides instructions for configuring each authentication option.
Authentication and timeout activities have the Code-Security class as the Applies To key part. Otherwise, you cannot access the activity on the Service tab of the Authentication Service form.
The standard LDAP authentication and timeout activities are LDAPAuthentication and LDAPAuthenticationTimeout. When you run the Authentication accelerator, it uses these two activities for the generated authentication service.
PRPC records log-in failures from any requestor type as an instance of the Log-SecurityAudit class. To obtain information about failed log-in attempts, run the standard list view rule named Log-SecurityAudit.ListOfLoginFailures. For each failed attempt, the ListOfLoginFailures report lists the time of the attempt, the server name and IP address of the system the attempt was made from, the Operator ID (if available), and the message that was returned. The pyRemoteHost property identifies the workstation or other system attempting log-in, and the pyRemoteID identifies the IP address.
The PRPC portlet service (based on JSR 168) provides access to a portlet Web application that your developers create. Your portlet application gathers and processes content from PRPC and displays the content and the processing results in a portlet window on a portal page in a Web browser.
A portal server manages the authentication of its users. Therefore, when a PRPC portlet is invoked, a user is already identified and there is no reason for that user to identify himself again to PRPC. The user credentials and identity are available, but this data must be transferred from the portal server to PRPC. The PRPC single sign-on feature manages the transfer of credentials.
Single sign-on is implemented through the authentication service feature. For portlets, single sign-on is implemented by default through a portlet authentication service named PRPortletService.
When you build portlets, you can use the initially supplied portlet authentication service to manage the identification of the portlet users. To do so, change the default settings to values appropriate for your system and modify the authentication activities as necessary. If the initial portlet authentication service does not meet your needs, you can configure a custom single sign-on or authentication scheme.
For more information, see Building Portlet Services, a document available on the PDN.
If your authentication scheme uses Microsoft's HTTP Negotiation extension and SPNEGO (Simple and Protected GSS-API Negotiation Mechanism), see PDN article How to implement single sign-on using SPNEGO and JAAS.
|
|
JNDI, LDAP-based authentication, portlet |
|
|
About JNDI Server data instances About Operator ID data instances About Organization Units |
About Authentication Services