Switch Access group for Rest API
We are planning to use service account for API calls, hence there is a requirement to switch access group of the service account dynamically runtime. PEGA invokes InitialProfileSetup(Final), ApplicationSetup(Extension available), ApplicationSetup(Extension available) during API calls if the APIs are secured. I tried to save the above extension activities under unauthenticated ruleset , my application ruleset and try to run the java code that switches access groups . But the ruleset stack does not pickup neither unauthenticated nor the application rulesets. I tried to add the access groups on to my Requestor Types, updated the service package access group etc. but the ruleset stack does not seem to reflect this. Any thoughts ?
Lventur
IN
Please try with the below mentioned java code for switching access group dynamically.
try { PRThread prtRef = tools.getThread(); if (prtRef != null) { ((com.pega.pegarules.priv.authorization.PegaAuthorization)prtRef.getAuthorization()).replaceAccessGroup(prtRef, AccessGroup); } } catch (Exception ilEx) { oLog.error("Error", ilEx); tools.putParamValue("test",ilEx.toString() ); }
For example you could refer pega OOTB activity to get some example how to dynamically change authorization context (access group)
Activity Name - pzSendEmailDigest
Avanade
SG
@Gunasekaran Baskaran Thanks for your reply. I already have this java code. My question is different, what is the ruleset that I need to check-in this code in to ? Is it unauthenticated ruleset or application ruleset ? Unfortunately, neither of them worked.
Lventur
IN
You could place the java code in your first step of service activity and dynamically change the authorization context (it should be in application rule-set).
Instead of placing the java code in any service pega OOTB activity extension place, you could place the logic in respective service activity itself. If you are placing the logic in any OOTB extension point then you might need to handle lot of exceptions, for other services/pega OOTB services which all you are using inside your application should not get affected because of this authorization context change logic.
Just the major configuration which we need to take care from our side is with the same name and and in same class we need to have the activity in all application(s) rule-set.
Ex
App 1 = ActivityName = TestServiceActivity, pxObjClass = Test-Int-ServiceActivity, Rule-Set = App1-01.01.01
App 2 = ActivityName = TestServiceActivity, pxObjClass = Test-Int-ServiceActivity, Rule-Set = App2-01.01.01
Pegasystems Inc.
GB
@Gunasekaran Baskaran , you need to follow these steps:
1.- Define a standard access group with access to the application which ruleset has the authentication activity. Typically this access group is called AppName:Unauthenticated.
2.- Define a custom authentication service with an authentication activity to do the switch between different operators or to set the required access group for the required operator.
3.- Update the service package for the API you want to use, to use the access group defined above, to "Require authentication" and to use the custom authentication service defined above.
This should allow you to authenticate and authorise the request into the right operator profile (access group)