How to integrate REST connector wih OAuth 1.0 for SHA-256
While attempting to connect to the client's OAuth service to get the security token, we found that the client requires us to use SHA-256 but that is not supported with the current OAuth profile.
The option we are thinking is to customize the Pega OOTB to pass the SHA-256 method in the Authorization header to retrieve the token. Not sue Pega will support just by changing the signature method with security features.
Is there any other better way, the Rest Integration can work for SHA-256.
Your suggestion are welcome.
***Edited by Moderator: Marissa to update categories & update SR Details***
That is the basic problem. The OOTB authentication profile only supports SHA-1, so we are having to do a work around in order to use 256 or higher. We are basically having to reverse engineer the whole Oauth process in order to make this work. Isn't there some way to get a patch so that could be done automatically?
Hitherto, the usage of Oauth 1.0 feature is limited to a very few customers, can we check with them if they can use OAuth 2.0, however if their respurce is protected with Oauth 1.0a that requires HMACSha256 , they require change sto the product to suppport it.
It involves the use of 2 activities
we should not be calling both pyConnectSocialNetwork and pyGetOAuthResource from the same activity. It's a two-step process. First pyConnectSocialNetwork should be called. In this step, user is authenticated against a Oauth 1.0a provider (for e.g. twitter) and an access token is retrieved. Then the call to pyGetOAuthResource is made. The first step of authenticating and getting an access token is asynchronous. So, if both pyConnectSocialNetwork and pyGetOAuthResource is called from the same activity, pyGetOAuthResource will get called before pyConnectSocialNetwork completes its job.
Basically, within the context of a flow the following needs to be done:
You can have one login/connect button clicking which would invoke pyConnectSocialNetwork activity.
You then have another button clicking which will invoke pyGetOAuthResource activity. This should be clicked only after step 1) completes.
Alternatively, instead of calling pyGetOAuthResource activity, A REST connector can be used to fetch the resource.
Create a REST connector, enable ‘Use authentication' and provide an authentication profile which uses OAuth authentication scheme linked to your OAuth1.0 based authentication profile. stp-2 can be then replaced with a call to the REST connector using activity step method Connect-REST
Now regarding the Issue customer is facing-
If we observe the above activities are starting with py meaning they can be overriden.
The following code needs to be overriden to have HMAC256 support
Changes to pyGetRequest activity
1)Create a new function and replace it in Step-6.
the function should replace the content of pzGenerateOauthSignature with HMACSha256
Hi Dass, in our scenario the OAuthProfile is used to store the OAuth1.0 details. What we found is that the pega default activity called in during the runtime is pyConnectOAuthProvider, which is not completely doing the job for getting the request token and access token to go for the protected resource.
Few things we did similar to mention above to generate the signature value for SHA256 and pass the method SHA26 by modifying the below activites.
1. pyConnectOAuthProvider - Modified to call the wrapper activity to get the request token and access token. This activity also check for the token exist from clientToken instance to avoid calling the Authinator again. So we customized to store the expiry time and valid during the open instance to reuse/request for new key.
2. pyGetRequestToken - Modified the JAVA step to pass the method and updated the function to call for SHA256.
3. pyGetAccessToken - With the same above modifications, added a new property to store the token expiry time to validate for re-use of token.
The challenge we faced is during the Access token retrieval and protected resource calling, the TokenSecret that pega sending is not working with in our boundary of the signature validation, so we used the function @decodeURLParameter to decode and then generate the signature.