Question
Deutsche Telekom Services Europe SE (DTSE)
DE
Last activity: 5 Oct 2022 16:23 EDT
Available Apps filtered on external authentication provider login method
Hi.
We have an external authentication provider which provides different methods of logins to the user (e.g. via windows credentials or smartcard). Depending on the chosen login method different sets of access groups in our Pega patform should be available for the user.
The authentication service is based on SAML 2 and we receive (next to general user information's) the chosen login method and the information about all possible accessgroups for the user in the SAML 2 token.
Information about which access groups are allowed in which login method are available in Pega.
All possible accessgroups are stored on the operator instance during the login. If we would only store the allowed access groups, based on the current login method, it would move the operator instance to a browser session related level, what it isn't. It is a platform instance and by this it needs all possible accessgroups. The login method is on browser session level and must be handled there.
To handle the requirement in a first step we would be able to stop the login on the Pega side in the postprocessing of the authentication method. But in case this will be passed and user is entering the application, than he could OOTB switch the accessgroup from a portal. Our current idea to limit the available access groups in the menue is to update the pxRequestor.pxSecuritySnapshot.pxAvailableApps list in the pyrequestorSetupExtension activity. But this update is not reflected from the system.
Hi.
We have an external authentication provider which provides different methods of logins to the user (e.g. via windows credentials or smartcard). Depending on the chosen login method different sets of access groups in our Pega patform should be available for the user.
The authentication service is based on SAML 2 and we receive (next to general user information's) the chosen login method and the information about all possible accessgroups for the user in the SAML 2 token.
Information about which access groups are allowed in which login method are available in Pega.
All possible accessgroups are stored on the operator instance during the login. If we would only store the allowed access groups, based on the current login method, it would move the operator instance to a browser session related level, what it isn't. It is a platform instance and by this it needs all possible accessgroups. The login method is on browser session level and must be handled there.
To handle the requirement in a first step we would be able to stop the login on the Pega side in the postprocessing of the authentication method. But in case this will be passed and user is entering the application, than he could OOTB switch the accessgroup from a portal. Our current idea to limit the available access groups in the menue is to update the pxRequestor.pxSecuritySnapshot.pxAvailableApps list in the pyrequestorSetupExtension activity. But this update is not reflected from the system.
Can some give me a feedback or hint, if we are on the correct way and explain the problem? Maybe there is a much better solution to handle the requriement?
Thanks in advance.
Regards, Matthias
***Edited by Moderator Marije to add Capability tags***
Mindtree Ltd
US
@MatthiasGuenther I dont think restricting in pxRequestor really stops the user from accessing the application if its still part of Operator access group list. We need to make sure.
There is a new feature added in 8.6 where you can define the list of authentication services using which access to an application is provided. If user logs in to that application with a different authentication service, error will be thrown. Please check if that helps you to meet your requirement.
If you want to achieve this through custom solution, first you need to find a solution on stopping/restricting access to an application - even though its added in Operator's AG list ( as you dont want to remove it from Operator record).
Check for an extension (for ex: ApplicationProfileSetup) that gets called on switch application, use that place to identify if user is allowed to access this application with the token you have in the session. You can achieve this using OOTB SamlLoginInfo DP or some custom requestor level DP. If user doesnt have access, thrown an exception.
Once the above requirement is met, now provide a custom 'switch to app' view which just lists out the Applications that are allowed to be accessed in the current session. Even if user, some how, tries to switch to the non-allowed application, the above logic should take care.
Note that this is just an idea to try with and I didn't personally implement :).
Thanks.