I’m working on a requirement where I need to implement a SAML 2.0 authentication service in Pega (Constellation 25).
Users will authenticate using their national ID, and the Identity Provider (IdP) will return user attributes, including this ID. In the application, we maintain a database table that stores user records along with their corresponding IDs and roles.
Based on the role associated with each user in this table, the system should automatically assign one or more appropriate access groups at login time.
I would like to ask:
What is the recommended approach to implement this type of authentication in Pega?
How can I dynamically assign one or multiple access groups based on the user’s role?
In Constellation 25, is it possible for a user to have two or more access groups and switch between portals? If so, what is the recommended way to configure this?
Any best practices or implementation guidance would be greatly appreciated.
You can use OOTB SAML2.0 Authentication Service. In the configuration, you can configure a Post Authentication Activity and write the logic to assign access group(s) dynamically based on the data received from IdP.
In Constellation, the best practice is to provide your user with a unique Persona (Access Group) for each of their applications. There is also no option to switch between multiple access groups/portals for each application as of now from end user portals. You can only switch across different applications. You can find more details about this in the below article by @MarcCheong
Use SAML attribute mapping to pass roles/groups from the IdP and map them directly to Access Groups during login.This approach ensures clean, standard, and maintainable authentication, with access control driven at login time rather than post-processing.Pega supports mapping IdP attributes to operator properties and access constructs like access groups.
Alternative option: You can leverage the Post-Authentication Activity to retrieve user details from your database (based on the ID received from SAML) and dynamically assign the appropriate Access Group(s). This is useful when roles are not managed in the IdP and instead stored in your internal tables.
In Constellation (25.x), (1 access group = 1 portal for 1 application). The user will have view for the default access group configured in Operator profile.. Technically we can have multiple access groups, but the end users can’t switch between portals as we do in traditional application.
Thank you very much @RameshSangili for your response. I will go with the alternative option, since the IdP does not provide the necessary data for assigning an access group. The required data is stored in Pega tables, so I will need to use a post activity.
I also understand the concept of having one portal per access group.
However, what is not clear to me is the statement in the Pega documentation: “You cannot change the Access Group of an operator in a postauthentication activity for an SSO authentication service.”
So how can an Access Group be assigned in a post activity? The documentation refers to the roles within an Access Group, but what I am interested in is assigning different Access Groups.
I would be grateful if you could clarify how this scenario should be handled.
I have implemented the solution as you suggested, and it is working correctly.
However, I am still curious about the statement in the Pega documentation: “You cannot change the Access Group of an operator in a postauthentication activity for an SSO authentication service.”
I’m asking mainly out of curiosity, as my current implementation seems to be working as expected.
Glad, it’s working . That’s because the user have to explicitly logoff and login to see the correct access group once after the operator profile is created.
. That’s because the user have to explicitly logoff and login to see the correct access group once after the operator profile is created.