@krishnamohanP8156  

Authentication of Service calls into Pega is controlled by the Service Package that the Service is attached to, which is defined by the first part of the Service-REST rule identifier. For example, the Pega API /cases/{ID} REST service in Pega 8.5 is bound to the "application" Service Package, which defines its Authentication Type as "OAuth 2.0". 

Pega needs to have authenticated the caller of the service before the Service Activity in your REST Service runs. It would be preferred if the callers of your Service can use "Basic" or "OAuth 2.0" authentication so that you don't have to implement custom authentication logic.

The Authorization HTTP header - including a "Basic" label in the value - is the transport for "Basic" authentication. If the Authorization header is for "Basic", and the rest of the value represents the username/password of an Operator ID in your Pega environment, then this should be a case of ensuring the Service Package of your REST Service is configured to use an Authentication Type of Basic. 

If your Authorization header however does not adopt the "Basic" scheme, and is some sort of 'custom' scheme, then you need to implement a custom Authentication Service and configure the Service Package to use an Authentication Type of "Custom". The activities running in an Authentication Service are the only rules that can access HTTP headers, so your Authorization header value will not be accessible anywhere else (including your Service Activity)

This is all possible, but adds effort and complexity. The recommendation is to implement your Pega services using Basic or OAuth 2.0 authentication so as to leverage out of the box authentication capabilities that align with industry authentication standards.