Difference between revisions of "Creating authentication registration for external users"

From PegaWiki
Jump to navigation Jump to search
(Initial curator review)
Tag: Visual edit: Switched
(Changed Application name - Daniela Siek)
Tag: Visual edit
 
(10 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
{{Design pattern
 
{{Design pattern
|Title=Best practices for creating authentication registration for external users
+
|Title=Creating authentication registration for external users
 
|Description=Best practices for creating authentication registration for external users
 
|Description=Best practices for creating authentication registration for external users
 
|Version=8.4
 
|Version=8.4
|Applications=
+
|Applications=Pega Platform
|Capability Area=
+
|Capability Area=Security
|Owner=
+
|Owner=Guyote, marty
 
}}
 
}}
  
The following are best practices to follow for authentication and registration of external users in public-facing applications (that is, applications whose operators are not client’s own employees). Users of such an application may be initially anonymous (identity unknown), and may have very restricted access to application features. They may then register themselves or have their identity verified partway through a session, and the session should continue transparently, with their operator context appropriately updated and with expanded privileges.
+
For authentication and registration of external users in public-facing applications (applications whose operators are not employees), the leading practices discussed in this article should be followed.  
  
A common example is an online shopping site, in which unauthenticated users can browse and add items to a shopping cart, and then they either create an account or enter their credentials to check out.
+
When using public-facing applications, users could initially be unauthenticated (anonymous and identity unknown), and may have very restricted access to application features. They may then register themselves or have their identity verified partway through a session, and the session should continue transparently, with their operator context appropriately updated and with expanded privileges.
  
Our best practices for this question are captured in the Community article listed below. The guidance is as follows:
+
For example, when going to an online shopping website, you may browse and add items to your cart without having an account or without signing into your account. In this case, you are browsing as an unauthenticated users and add items to a shopping cart, and then they either create an account or enter their credentials to check out.
* Use the out-of-the-box Authentication Service rule of the Anonymous type for authentication. In that rule, specify an access group with the appropriate extremely-limited privileges that should be sufficient for an anonymous user. The privileges would usually ensure that such users can only use the case types required for them to create their cases, can only access data they have created themselves, and have no access to other application functionality, such as reporting, etc.
 
* Once an end user is authenticated with a known identity, use the Re-Authentication gadget to change their context and access group info, rather than writing custom code.
 
* In public-facing applications where end users do not need access to information about other operators, we recommend that you restrict all access to data in the ''Data-Admin-OperatorID'' class to only the end user’s data through an access control policy. You can do this by enabling the out-of-the-box rules ''pyDefault'' and ''pyRestrictToSelf'' in the ''Data-Admin-OperatorID'' class.
 
  
Please refer to the following articles on Pega Community for more information:
+
Industry leading practices are detailed in [https://community.pega.com/knowledgebase/articles/application-development/84/basic-requirements-deploying-public-facing-applications ''Basic requirements for deploying public-facing applications'']. The general take-aways from this article are as follows:
 +
* Use the out-of-the-box Authentication Service rule of the Anonymous type for authentication.
 +
** In that rule, specify an access group with the appropriate extremely-limited privileges that should be sufficient for an anonymous user. The privileges would usually ensure that such users can only use the case types required for them to create their cases, can only access data they have created themselves, and have no access to other application functionality, such as reporting, etc.
 +
* Use the Re-Authentication gadget to challenge the user to enter login credentials and change their context and access group information, rather than writing custom code.
 +
* In public-facing applications where end users do not need access to information about other operators, we recommend that you restrict all access to data in the <code>Data-Admin-OperatorID</code> class to only the end user’s data through an access control policy. You can do this by enabling the out-of-the-box rules <code>pyDefault</code> and <code>pyRestrictToSelf</code> in the <code>Data-Admin-OperatorID</code> class.
  
[https://community.pega.com/knowledgebase/articles/application-development/84/basic-requirements-deploying-public-facing-applications Basic requirements for deploying public-facing applications]
+
For more information, see the following articles on Pega Community:
 
+
* [https://community.pega.com/knowledgebase/articles/application-development/84/basic-requirements-deploying-public-facing-applications Basic requirements for deploying public-facing applications]
[https://community.pega.com/knowledgebase/articles/security/84/security-checklistt Security Checklist]
+
* [https://community.pega.com/knowledgebase/articles/security/84/security-checklist Security Checklist]

Latest revision as of 16:10, 10 June 2021

Creating authentication registration for external users

Description Best practices for creating authentication registration for external users
Version as of 8.4
Application Pega Platform
Capability/Industry Area Security



For authentication and registration of external users in public-facing applications (applications whose operators are not employees), the leading practices discussed in this article should be followed.

When using public-facing applications, users could initially be unauthenticated (anonymous and identity unknown), and may have very restricted access to application features. They may then register themselves or have their identity verified partway through a session, and the session should continue transparently, with their operator context appropriately updated and with expanded privileges.

For example, when going to an online shopping website, you may browse and add items to your cart without having an account or without signing into your account. In this case, you are browsing as an unauthenticated users and add items to a shopping cart, and then they either create an account or enter their credentials to check out.

Industry leading practices are detailed in Basic requirements for deploying public-facing applications. The general take-aways from this article are as follows:

  • Use the out-of-the-box Authentication Service rule of the Anonymous type for authentication.
    • In that rule, specify an access group with the appropriate extremely-limited privileges that should be sufficient for an anonymous user. The privileges would usually ensure that such users can only use the case types required for them to create their cases, can only access data they have created themselves, and have no access to other application functionality, such as reporting, etc.
  • Use the Re-Authentication gadget to challenge the user to enter login credentials and change their context and access group information, rather than writing custom code.
  • In public-facing applications where end users do not need access to information about other operators, we recommend that you restrict all access to data in the Data-Admin-OperatorID class to only the end user’s data through an access control policy. You can do this by enabling the out-of-the-box rules pyDefault and pyRestrictToSelf in the Data-Admin-OperatorID class.

For more information, see the following articles on Pega Community: