A complex security-based architectural requirement
Hello.
I'm struggling with a real tough architectural concern and I'm looking for any insight/thought.
Here is the deal:
There are two "zones" defined here: the Internet zone and the Intranet zone. And in terms of communications between these two zones, the most important rule is that nothing defined in the Intranet zone can be directly accessed and (even more so) modified from the Internet zone. Whenever an action is performed on a Intranet resource from the Internet zone, there must be what is called here a "rupture of protocol": basically the action must be realized through a (web) service call which has been rightfully published in a chain of gateways and proxies responsible for managing the security aspects of such service calls.
Basically, we're going to have a Pega server in the Intranet zone. Of course, there will be Intranet users who will be able to connect to a portal defined in Pega (with SSO-based authentication/authorization) in order to "do whatever they are authorized to do").
BUT there will also be Internet users who will have to use an external user portal (defined in the Internet zone) in order, basically, to start cases (inputting some data) and later to consult their own list of opened cases.
Hello.
I'm struggling with a real tough architectural concern and I'm looking for any insight/thought.
Here is the deal:
There are two "zones" defined here: the Internet zone and the Intranet zone. And in terms of communications between these two zones, the most important rule is that nothing defined in the Intranet zone can be directly accessed and (even more so) modified from the Internet zone. Whenever an action is performed on a Intranet resource from the Internet zone, there must be what is called here a "rupture of protocol": basically the action must be realized through a (web) service call which has been rightfully published in a chain of gateways and proxies responsible for managing the security aspects of such service calls.
Basically, we're going to have a Pega server in the Intranet zone. Of course, there will be Intranet users who will be able to connect to a portal defined in Pega (with SSO-based authentication/authorization) in order to "do whatever they are authorized to do").
BUT there will also be Internet users who will have to use an external user portal (defined in the Internet zone) in order, basically, to start cases (inputting some data) and later to consult their own list of opened cases.
I don't think using IAC/Mashup is an option here. Unless I'm mistaken, that would mean displaying Pega-generated UI in the external portal and allowing direct actions on the Pega server without going through all the security mechanisms implementing the "rupture of protocol". Right? Unless of course there is some way (that I don't think/know of) to specify that the click on a submit button in that case is not an action on the Pega server but a service call through a chain of gateways/proxies before it's arriving on the Pega server.
One solution I can think of is having 2 Pega servers: one in the Internet zone and one in the Intranet zone. The one in the Internet zone would implement the parts of the processes used by Internet-side users with (when needed) calls to services implemented by the Pega server on the Intranet side. But additionally, it seems that everything on the Internet-side Pega server will have to be totally stateless, without any data stored. The one in the Intranet zone would implement the parts of the processes used by Intranet-side users and provide the services to be called by the Internet-side Pega server.
Basically I'm looking for any solution that would allow us to have just one Pega server (on the intranet side) and still being compliant with the "rupture of protocol" security requirements.
Any thought? Previous successful experience dealing with this kind of issue?
Thanks a lot.