Question
Bradesco Seguros
BR
Last activity: 21 Mar 2017 9:31 EDT
External Authentication on PEGA
Although the IAC has been proposed to the client, with the use of the PEGA Marshup, the client have not accepted and left for a desire for the solution that works, with the following logic:
1 - Customer external user uses an external portal, called "100% Corretor", where he informs his CPF or CNPJ (User Identification Number) and its respective password.
2 - The portal, upon receiving this information, goes to a security database, where it validates the client's security data and generates a token (Creating an encryption of this access information).
3 - After this validation was performed, a link would be made available for the user to access the PEGA.
In step 3 is one of the big questions, where we have questions and need clarification. According to Costumer, PEGA should provide an access URL, where the portal could inform the Token generated in step 2, as follows:
Example:
http://z-intranet-pega.dsv.bradseg.com.br/prweb/PRServlet/crypt? DA7ABF695029C4F0EF26AC38B3D547E350F2DCAC40226008426E91494CAA003B727124B8CEFD7985FE1F3FB34D01
Although the IAC has been proposed to the client, with the use of the PEGA Marshup, the client have not accepted and left for a desire for the solution that works, with the following logic:
1 - Customer external user uses an external portal, called "100% Corretor", where he informs his CPF or CNPJ (User Identification Number) and its respective password.
2 - The portal, upon receiving this information, goes to a security database, where it validates the client's security data and generates a token (Creating an encryption of this access information).
3 - After this validation was performed, a link would be made available for the user to access the PEGA.
In step 3 is one of the big questions, where we have questions and need clarification. According to Costumer, PEGA should provide an access URL, where the portal could inform the Token generated in step 2, as follows:
Example:
http://z-intranet-pega.dsv.bradseg.com.br/prweb/PRServlet/crypt? DA7ABF695029C4F0EF26AC38B3D547E350F2DCAC40226008426E91494CAA003B727124B8CEFD7985FE1F3FB34D01
When to access the address of PEGA, it would inform the part of the address that is marked in red, the token that it obtained in step 2, in this way the PEGA would then call the decode integration that Uses a rest connector, which, through this Token as input, is able to obtain user access information (Name, CPF / CNPJ, Profile ..) and then check if there is already an operator created for it through the CPF / CNPJ recovered. If this operator does not exist, the PEGA should create the same, through the profile obtained, enabling the group of access and application that it should use.
Regarding the issues above, I would like to evaluate some points w:
1 - How could we expose a URL address for external access, which could receive a token in rest format, so that PEGA validates itself and allows the external user access to the application?
2 - Is there any POC or other technical documentation that could clarify that this is a viable solution to be applied and can guide in the construction?
3 - What type of architecture solution should we take into consideration in PEGA, in order to follow the application pattern and not generate a solution that is not valid ?
Regards