Hello. 

Pega documentation of earlier releases refer to use of the facade to the HttpServletRequest Java object in the only in the context of the PRCustom authentication scheme.

It detailed the pxRequestor.pxHTTPServletRequest Property and the text states "Only authentication activities invoked through an authentication service have access to the pxRequestor.pxHTTPServletRequest property."

 PRCustom authentication scheme does allow access to the HttpServletRequest (via parameters or the Facade object) but  I'm afraid that out of the box, there is still only access to the façade object.

There are reasons why we use this façade object:
 
1. Serializability across e-tier boundaries:  To support PRPC deployments using remote EJB calls, where the servlet isn't running in the same container as our EJB, we construct a facade object that is fully serializable so we can guarantee some access to values in the request/response objects across the boundary.  The HttpServletRequest object itself isn't serializable, so that's the motivation behind mocking up a facade object that captures just enough state information for use by custom authentication and can cross the e-tier boundary through remote invocation.
 
Support of this remote EAR configuration using a facade  is important so that PRPC applications (and PRPC itself) aren't written to run only in WAR or local EAR deployment styles, but are guaranteed to work in different deployment scenarios.
 
2. Container security constraints: Since we build up that facade object, we have to capture state data about the request in the facade and store it.  Since there's no J2EE API that will give us all the roles currently available to the user, we aren't able to proactively store a list of available roles and provide an answer for a isUserInRole() style API method.
 
3.  Performance:  We only provide the facade at login for use with custom authentication.  If we had to construct the facade on every HTTP request to make sure we had the current data needed for the request API, it would be prohibitively expensive.
  
This implies that if PRPC was providing the original session object, PRPC woudn’t be guaranteed to work in different deployment scenario.
It is possible to configure the authentication in order to retrieve whatever HTTP header presumably used by this third party for authentication. 

Other documentation that supports our explanation is here:

https://community.pega.com/support/support-articles/unable-read-http-session-authentication-activity