We are using PEGA 8.1.2 with SAML authentication to implement SSO.
As per our project requirement we wanted to create operator id on the fly based on the LDAP group info coming in the SAML request.We don't want to use the model operator configuration provided on SAML rule to create the operator id on the fly.
We wanted to use a table configuration where the LDAP group to access group mapping is provided to create operator id. We are looking to find the hook up point where we can have our custom logic to identify the access group and create the operator id.
In PEGA previous versions like till 7.4 v the customization can be done in the following activities. pySAMLWebSSOAuthenticationActivity and pyEstablishOperatorContext available at Code-Security class.
We have tried to trace the browser session to find out if the same activities are getting called but these rules are not getting called. Instead D_SamlSsoLoginInfo, D_SAMLAssertionDataPage and D_pzSSOAttributes these data pages are getting called.
Could you please confirm what activity is being called at the time of authentication. So that we can do customization to fulfill our project requirement.
There is no activity being called anymore. The new PRAuth AuthService is the no code approach. As in there are no longer activities that hold core SAML related java code.
To accomplish what you are trying to do you use a model operator, just for base info, along with the mapping tab that has full support for data pages. So you would reference properties from a data page in the map from and map to properties in the map to.
The data page can use an activity as the source of the page. This is where you add your customizations now. You can reference data from the D_SAMLAssertionDataPage and set your map from properties as needed.
Note: In 8.2+ there is also an option to use Data Transform for operator provisioning.
Thanks Chris for high-level explanation of how to do this in 8.x, but surely there is a Design Pattern document created to explain How To do this same thing in 8.x
Given how many applications out there already implemented a dynamic operator SSO solution leveraging model operators, surely a 'How To in 8.2" was made to support so many Clients upgrading to 8.x from 7.
I have implemented the solution provided by you and mapped the SAML fields using a data page. But this fields mapping is not supporting mapping of multiple AD groups mapping to the operator Id dynamically as we are hard coding the indexes. The same issue for skills and work baskets mapping.
Hi, I have a question here. The mapping tab and the Data Trasnform being talked about doesnt get called if the operator is already existing. If I need to update any value every time the operator logs in I understand we need to use the post Authentication Activity, which runs in the context of the logged in user and not the Unauthenticated AccessGroup. Now what if the logged in Operator doesn't have the privilege of updating a Data- class?
So did I! It did raise a question for me though. The provisioning logic executes when the operator does not exist. So for existing operators I assume the logic on the Mapping tab then executes? Therefore that tab will be doing the same mapping as done in the data transform for provisioning an operator.