Skip to main content

This content is closed to future replies and is no longer being maintained or updated.
Links may no longer function. If you have a similar request, please write a new post.

Question

 Rajasekar Jayaraman (RajaseakDJ)
Cigna - EverNorth

Cigna - EverNorth
US
RajaseakDJ Member since 2017 1 post
Cigna - EverNorth
Posted: Jun 28, 2017
Last activity: Jul 7, 2017
Posted: 28 Jun 2017 14:08 EDT
Last activity: 7 Jul 2017 15:32 EDT
Closed

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***

To see attachments, please log in.
Data Integration
Support Case Exists

Posted: 7 years ago
Posted: 30 Jun 2017 15:26 EDT
Syl schinco (SylSchinco_GCS) Technical Solutions Engineer
Pegasystems Inc.
US

Based on the SR that was raised and redirected to the support community (here), he's on Pega 7.2.1

 

I looked at the code of pzGenerateOauthSignature, and it appears to only call HMAC SHA-1, with no option to use SHA-256 or SHA-512.

To see attachments, please log in.
Posted: 7 years ago
Posted: 6 Jul 2017 9:33 EDT
Chris Boone (Chris_Boone)
PEGA
Enterprise Technical Solutions Director
Pegasystems Inc.
US

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?

 

To see attachments, please log in.
Posted: 7 years ago
Posted: 6 Jul 2017 22:45 EDT
Santosh Das (DASS1)
PEGA
Architect
Pegasystems
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 
1)pyConnectSocialNetwork
2)pyGetOAuthResource
 
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.
Show More
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 
1)pyConnectSocialNetwork
2)pyGetOAuthResource
 
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
 
byte[] byteHMAC = null;
try 
{
   Mac mac = Mac.getInstance("HmacSHA256");
   SecretKeySpec spec;
   String oauthSignature;
   oauthSignature = pega_integrationengine_oauthutilities.pzURLEncode(consumerSecret) + "&" + pega_integrationengine_oauthutilities.pzURLEncode(tokenSecret);
   
   spec = new SecretKeySpec(oauthSignature.getBytes(), "HmacSHA256");            
   mac.init(spec);
   byteHMAC = mac.doFinal(baseString.getBytes());
} 
catch (InvalidKeyException e) 
{
   e.printStackTrace();
} 
catch (NoSuchAlgorithmException ignore) 
{
   // should never happen
}
return Base64Util.encodeToString(byteHMAC);
 
 
2)Step-3 of pyGetProtectedResource activity should be replaced with the following
java.util.HashMap hashData = new java.util.HashMap();
 
// add query string parameters, if any, to the hash map
String url = resourceURL;
int index = url.indexOf("?");
if (-1 != index) {
  url = url.substring(index + 1);
  hashData = (java.util.HashMap) StringUtils.parseQueryString(url);
}
 
// add OAuth protocol specific parameters
hashData.put("oauth_timestamp", timestamp);
hashData.put("oauth_nonce", nonce);
hashData.put("oauth_consumer_key", tools.getParamValue("ConsumerKey"));
 
if(myStepPage.getString("pySignatureMethod").equals("HMACSha256"))
    hashData.put("oauth_signature_method", "HMAC-SHA256");
else if(myStepPage.getString("pySignatureMethod").equals("PLAINTEXT"))
    hashData.put("oauth_signature_method", "PLAINTEXT");
 
 
hashData.put("oauth_version", "1.0");
hashData.put("oauth_token", tools.getParamValue("Token"));
 
headerData = hashData;
 
 
 
Please let me know if they face issues after this change, we will have to backtrack it from there.

Show Less
To see attachments, please log in.
Posted: 7 years ago
Posted: 7 Jul 2017 15:32 EDT
Rajasekar Jayaraman (RajaseakDJ)
Cigna - EverNorth

Cigna - EverNorth
US

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.

Regards,

DJ

To see attachments, please log in.

We'd prefer it if you saw us at our best.

Pega Collaboration Center has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice