Ravi,

I am answering the question you have posted here and also these related questions:

Can we add a certificate to IAC pegagateway to authenticate as a client?

IAC authentication for external application using .NET Forms Authentication

Your Environment/Requirements:

• PRPC 7.1.8
• Mashup implementation with a .NET application.

Same Domain Origin Policy:

With your version of PRPC the #1 requirement when building a mashup is satisfying Same Domain Origin Policy. At run time the PRPC Gadget definition, the DIV element, is read/parsed and an iframe is created as a child element.  The PRPC content is displayed within the iframe so in order for the top level application and PRPC to talk to each other Same Domain Origin Policy is required.  This allows for the PegaE gadget events to work and also data binding.

PRPC 7.2.1:

When this new version of PRPC is released there is no PRGateway and no requirement for Same Domain Origin Policy. Communication between the top level and PRPC application is handled using a trust method that allows for the communication to and from the PRPC iframe.  (PDN information will be up shortly after the release)

Is PRGateway needed?

The PRGateway is a tool that you can use within your environment to help satisfy Same Domain Origin Policy and also be used outside of a DMZ for security purposes although you still have to secure PRGateway access. There is no requirement per say that it has to be used.  If you can satisfy Same Domain Origin policy with out PRGateway then you don't need to use it.  I have samples from as old as PRPC 6.1SP2 that don't use the PRGateway and go directly to PRPC.  The general functionality of PRGateway is it acts as a proxy server. It's taking requests in from the browser, parses them, creates a new connection to PRPC to send and receive, takes the response from PRPC and sends it to the browser.

From a security standpoint you could use the PRGateway outside of a DMZ:

Browser -> PRGateway -> Firewall -> PRPC

With a mashup within a .NET application the PRGateway makes no sense for the environment. You should not use it.

IIS Server Reverse Proxy:

With your environment it would make more sense to use a reverse proxy configuration within the IIS server and defined within the top level application site level.

• IIS Sever: Requires ARR to be installed (Application Request Routing)
• IIS Sever: UrlMaxSegmentLength increased from 260 to 2048 (https://docs.microsoft.com/en-US/troubleshoot/iis/httpsys-registry-windows)
  • HKEYLOCALMachine/system/current control set/services/http/parameters/UrlSegmentMaxLength  (DWORD) set to 2048
  • Required for IIS front ending PRPC requests, default UrlMaxSegmentLength is two low.  (Many support request related to this)
• PRPC: Add the following to the PRPC prconfig.xml:
  • <env name="initialization/ContextRewriteEnabled" value="true"/>

Note: The following are setup images from my IIS server with some modification for usage in this post.  I am in no way an IIS expert as this is the Pegasystems support forum and not the IIS support forum. Consult your IIS documentation and administrator. This is just used to help explain a setup that does not use the PRGateway for a .NET mashup. Same can be done using Apache and mod_proxy.

• Create a URL Rewrite rule.  Image shows "default web site" as that is all I have right now. You would define this under you top level application site.

• Use a Reverse Proxy Rule:

• Specify you PRPC host name for the inbound rule, use the PRPC load balancer host if you have multi node.
• Use SSL offloading if you want
• No outbound rule required.

• Add HTTP_PegaRULES-SetContextURI  to the allow server variable list.  This is used to send the HTTP header PegaRules-SetContextURI to PRPC when the request is is proxied to PRPC.

• Edit inbound rule
• Modify pattern to something unique and not used by the top level application. In this example i have used "toprpc(.*) which will patch on "/toprpc".
• Add the server variable HTTP_PegaRULES-SetContextURI with a value equal to URL being used by the top level host plus "/toprpc/prweb"
• In action properties make sure you use "prpc_host/{R:1}" and append query string.

Gadget Config:

Now using this type of proxy setup I would specify the following for the gatewayURL when developing the gadget to be included in the top level application:

<script>

pega.web.config.gatewayURL="/toprpc/prweb/IAC";

...

</script>

Requests to http://toplevelhost/toprpc/prweb/IAC will now be proxied to PRPC. I have satisfied Same Domain Origin Policy because i have used a relative link.

The IAC servlet is the same thing you would use when configuring the PRPC host in the PRGateway application.

Security/PRPC Authentication:

Since the proxy to PRPC is defined at the IIS site level any existing authentication that you have in place for the top level application will protect calls to /toprpc/prweb/IAC. The PRPC system can be behind firewalls etc as it's the IIS system that will be sending requests to PRPC, not the browser.

If this is an internet facing application and no users can directly access PRPC with out first authenticating with the top level application.

Examples:

Browser -> IIS (Authentication) -> firewall -> PRPC

Browser -> Authentication -> firewall -> IIS -> PRPC

Since the authentication is already done at the top level you can simply send us the user id of the user using the top level application. Also other security level cookies will also be sent or configured to be sent to PRPC during the proxy that could further be used for security. 

PegaA_params="{UserIdentifier:'[Current_User_ID]'}">

PRPC Authentication for the IAC servlet is handled using the Data-Admin-AuthService instance IACAuthentication. Make sure you switch the mode on the custom tab to "Use External Authentication".  Out of the box if you send us a User ID that already has a corresponding Data-Admin-Operator-ID it will log you in as that user.  You can modify the login activity to fit your needs.  (I can help with that as well if you want but beyond the scope of this post)

Ravi,

I am answering the question you have posted here and also these related questions:

Can we add a certificate to IAC pegagateway to authenticate as a client?

IAC authentication for external application using .NET Forms Authentication

Your Environment/Requirements:

• PRPC 7.1.8
• Mashup implementation with a .NET application.

Same Domain Origin Policy:

With your version of PRPC the #1 requirement when building a mashup is satisfying Same Domain Origin Policy. At run time the PRPC Gadget definition, the DIV element, is read/parsed and an iframe is created as a child element.  The PRPC content is displayed within the iframe so in order for the top level application and PRPC to talk to each other Same Domain Origin Policy is required.  This allows for the PegaE gadget events to work and also data binding.

PRPC 7.2.1:

When this new version of PRPC is released there is no PRGateway and no requirement for Same Domain Origin Policy. Communication between the top level and PRPC application is handled using a trust method that allows for the communication to and from the PRPC iframe.  (PDN information will be up shortly after the release)

Is PRGateway needed?

The PRGateway is a tool that you can use within your environment to help satisfy Same Domain Origin Policy and also be used outside of a DMZ for security purposes although you still have to secure PRGateway access. There is no requirement per say that it has to be used.  If you can satisfy Same Domain Origin policy with out PRGateway then you don't need to use it.  I have samples from as old as PRPC 6.1SP2 that don't use the PRGateway and go directly to PRPC.  The general functionality of PRGateway is it acts as a proxy server. It's taking requests in from the browser, parses them, creates a new connection to PRPC to send and receive, takes the response from PRPC and sends it to the browser.

From a security standpoint you could use the PRGateway outside of a DMZ:

Browser -> PRGateway -> Firewall -> PRPC

With a mashup within a .NET application the PRGateway makes no sense for the environment. You should not use it.

IIS Server Reverse Proxy:

With your environment it would make more sense to use a reverse proxy configuration within the IIS server and defined within the top level application site level.

• IIS Sever: Requires ARR to be installed (Application Request Routing)
• IIS Sever: UrlMaxSegmentLength increased from 260 to 2048 (https://docs.microsoft.com/en-US/troubleshoot/iis/httpsys-registry-windows)
  • HKEYLOCALMachine/system/current control set/services/http/parameters/UrlSegmentMaxLength  (DWORD) set to 2048
  • Required for IIS front ending PRPC requests, default UrlMaxSegmentLength is two low.  (Many support request related to this)
• PRPC: Add the following to the PRPC prconfig.xml:
  • <env name="initialization/ContextRewriteEnabled" value="true"/>

Note: The following are setup images from my IIS server with some modification for usage in this post.  I am in no way an IIS expert as this is the Pegasystems support forum and not the IIS support forum. Consult your IIS documentation and administrator. This is just used to help explain a setup that does not use the PRGateway for a .NET mashup. Same can be done using Apache and mod_proxy.

• Create a URL Rewrite rule.  Image shows "default web site" as that is all I have right now. You would define this under you top level application site.

• Use a Reverse Proxy Rule:

• Specify you PRPC host name for the inbound rule, use the PRPC load balancer host if you have multi node.
• Use SSL offloading if you want
• No outbound rule required.

• Add HTTP_PegaRULES-SetContextURI  to the allow server variable list.  This is used to send the HTTP header PegaRules-SetContextURI to PRPC when the request is is proxied to PRPC.

• Edit inbound rule
• Modify pattern to something unique and not used by the top level application. In this example i have used "toprpc(.*) which will patch on "/toprpc".
• Add the server variable HTTP_PegaRULES-SetContextURI with a value equal to URL being used by the top level host plus "/toprpc/prweb"
• In action properties make sure you use "prpc_host/{R:1}" and append query string.

Gadget Config:

Now using this type of proxy setup I would specify the following for the gatewayURL when developing the gadget to be included in the top level application:

<script>

pega.web.config.gatewayURL="/toprpc/prweb/IAC";

...

</script>

Requests to http://toplevelhost/toprpc/prweb/IAC will now be proxied to PRPC. I have satisfied Same Domain Origin Policy because i have used a relative link.

The IAC servlet is the same thing you would use when configuring the PRPC host in the PRGateway application.

Security/PRPC Authentication:

Since the proxy to PRPC is defined at the IIS site level any existing authentication that you have in place for the top level application will protect calls to /toprpc/prweb/IAC. The PRPC system can be behind firewalls etc as it's the IIS system that will be sending requests to PRPC, not the browser.

If this is an internet facing application and no users can directly access PRPC with out first authenticating with the top level application.

Examples:

Browser -> IIS (Authentication) -> firewall -> PRPC

Browser -> Authentication -> firewall -> IIS -> PRPC

Since the authentication is already done at the top level you can simply send us the user id of the user using the top level application. Also other security level cookies will also be sent or configured to be sent to PRPC during the proxy that could further be used for security. 

PegaA_params="{UserIdentifier:'[Current_User_ID]'}">

PRPC Authentication for the IAC servlet is handled using the Data-Admin-AuthService instance IACAuthentication. Make sure you switch the mode on the custom tab to "Use External Authentication".  Out of the box if you send us a User ID that already has a corresponding Data-Admin-Operator-ID it will log you in as that user.  You can modify the login activity to fit your needs.  (I can help with that as well if you want but beyond the scope of this post)