More about
Authentication Service data instances
|
|
You can configure your Process Commander system to authenticate users in one of several ways:
The publication 
Authentication in
PegaRULES Process Commander, a document available on the
Pega Developer Network, provides an in-depth description of how
authentication works, including how Process Commander 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.
Process Commander 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 identifiers the workstation or other system attempting log-in, and the pyRemoteID identifies the IP address.
The Process Commander 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 Process Commander 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 Process Commander portlet is invoked, a user is already identified and there is no reason for that user to identify himself again to Process Commander. The user credentials and identity are available, but this data must be transferred from the portal server to Process Commander. The Process Commander 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 Pega Developer Network.
If your authentication scheme uses Microsoft's HTTP
Negotiation extension and SPNEGO (Simple and Protected GSS-API
Negotiation Mechanism), see Pega Developer Network article
PRKB-24115 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 |