A complex security-based architectural requirement
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?
The security system (consisting in this "rupture of protocol" policy) is already implemented and it's IS-wide.
The problem is what are the possible options to have a Pega server in the intranet zone AND to have access for users from the internet zone WHILE complying to the "rupture of protocol" security constraint.
- a Mashup doesn't seem to be an option: it is going against the "rupture of protocol" policy as features "living" on the Pega server in the intranet zone are directly accessible from the internet zone
- using the REST API in order to drive the process from the internet zone is an option: the features are only accessible through the services provided by the REST API and these servicescan be published in the different layers of the security system. So it is compliant to the "rupture of protocol" security policy.
I'm looking for any other solution which is:
- as "simple" as the Mashup solution
- and still compliant to the "rupture of protocol" security policy like the use of the REST API is.
To have everything on same server, one approach I could think of is this. You can expose the internet portal on the same server,but with minimum access permissions (restrict everything except executing configured actions). And on click of the actions, you can configure to call the service exposed on the same Pega server which will go through the all security checks in place.