I am extremely interested in this thread and I can't sleep so I will give a quick overview (or semi-intelligent rant) of how we achieved this with one of my current clients (with no sensitive or client information exposed obviously)
(My caveat to these points below are there are many way to expose your internal environments and this is by no means an instruction list just some pointers from one of my recent clients, there are many more security implications that need fully discussed with senior architechts on site regarding the companies particular policies)
i) There is an internet URL required that resolves (generally via a DNS A record to your corporate external fixed IP address) i.e. in the exposing recruitment scenario http://recruit.myplc.com
ii) myplc.com's fixed IP will then firewall this and port forward (possibly remove the https via installed certificates and SSL termination on their network equipment - not too important to a Portal implementor as long as they route traffic to your reverse proxy server/s within a DMZ - but a note a Portal Implementor should work closely with the person requesting the SSL certificates from whichever recognised company they choose noting the expiration and the browsers that recognise that companies SSL cert - that is something that is sometimes overlooked)
iii) In reference to ii) your DMZ reverse proxy server will generally have 2 NIC's, one external facing and one internal facing. PeopleSoft offers many options to reverse proxy requests from your DMZ to your internal architecture, IIS, Apache etc. My previous experience we have used IIS accepting incoming traffic on Port 80 after SSL has been terminated by corporate network equipment, this can also balance incoming requests across several reverse proxies, in my previous experience I have used Cisco ACE load balancing equipment, from a PeopleSoft perspective we don't need to know too much about these boxes, but we should be aware how they handle 'Stickyness' i.e. between reverse proxies (or internal load balancers)
iv) I am not completely up to date on PeopleSoft plug-in architecture but again from experience I have used WebSphere plug-ins to forward traffic to internal WebSphere PIA's, my personal feeling is the PS plug-ins from reverse Proxies only make sense if you are specifically clustering internal servers from the DMZ, I think the Red Paper says that too. Apache/IIS offers rewrite rules that work equally as well on single PIA systems, if you are clustering internal PIA's then consider the vendor plug-ins. Plug-in rules are fairly easy to write and once you decide on the virtual host (generally the external URL you are using, and the port (80 if it is terminated)) then you just need to tell the plug in where to send incoming requests to. This is a slightly complicated area and there is no 'one size fits all' policy every organisation is different. Another point to be aware of at this point is building in rules to your DMZ reverse proxy, some important ones that I have found are:
a) A default installed plug-in will allow all http/s request to travel internally, in the plug-in you can restrict requests, if you are only exposing in this example a RECRUITMENT portal, then there is no reason to let any traffic past other than recruit.myplc.com/psc/*yourPIAname*/RECRUITMENT traffic through, this can be restricted in the plug-in. We have discussed the portal so we could also restrict psp traffic (as long as you are only delivering content dont give access to your PS application) this could prevent malitious people from gaining access to your internal pages. It is worth mentioning at this point that penetration testing is vital to a Portal implemntor and should never be taken personally, I have learned a few things from this.
b) At the plug-in level all webservers have the ability to forward any other external URL's to internal addresses via rewrite rules too, i.e. register.recruit.myplc.com as an external address could rewrite at your webserver to recruit.myplc.com/psc...blah**register page**, once the web server rewrites it to the recruit.myplc.com address then the plug-in will deal with it and forward the address in it's entirity to the relevant internal PS address. Happy to elaborate if anyone is interested in rewrite rules, I can help in Apache and IIS, again this is a very client specific requirement.
v) OK, assuming the a customer has typed https://recruit.myplc.com your external ISA/ACE has terminated SSL, your reverse proxy has received and rewritten, and forwarded it to your internal PIA in your organisation, you have obviously had a discussion with your network guys :) the PIA you have built (i.e. on port 3456) has had network traffic requested to have been opened to allow traffic from all your reverse proxies in the DMZ, to pass through your internal firewall for port 3456. That being the case we can discuss the internal PIA. (there are other options to build PIA's in the DMZ the red paper details it but I am discussing my most recent client implementation)
vi) Depending on the applications you are exposing, I will use Recruitment as an example here, you need to build a PIA to expose HR(With the recruitment module), you need a different PIA than the one you use if you expose it internally, fairly obvious I know but you need two different web profiles, this applies to all applications, i.e. if you are exposing https://recruit.myplc.com and you access it internally as http://getmeanewjob.company.loc then at the very minimum your web profiles will differ by using a default port on your external address of 443 and possibly recruit.myplc.com.
vii) Moving on from this into the internal application servers used, and one I dont think is discussed largely in the Red paper is in my opinon never ever use the same application servers you use for your internal customers as that for external customers - I have seen things fall down here, you can't restrict your internal customers ability to do their job based on unusual external activity. Moving on to the point of separation, separate out as much as you can i.e. run external webs/apps on different servers, integration brokers on different servers, in virtualisation sometimes this doesn't make much of a difference unless you cap server usage.
I know some of my points may be vague but experiences shared, and points raised by you guys can only make us better IT dudes supporting our clients.
I have missed out a whole section on internal load balancing above, section ii)
If anyone would like to quiz me on any of the above I am more than happy to PM or group forum.
Mr Kurtz promotes this knowledge sharing I think :)
--- In email@example.com, "David Kurtz" <david.kurtz@...> wrote:
> One of my customers is looking at exposing their PeopleSoft HR system to the
> public internet to do on-line recruitment. I am part of a conversation
> about exactly how to architect that. I have my views on how this should be
> done, but I am interested in finding out how other people have actually done
> it. I have already asked some of my friends how they have done this, and I
> have had a range of answers. So, I am conducting an informal survey.
> Can you tell me how you have arranged that? Ie:
> What is the arrangement in the DMZ? What components are in the DMZ
> Do you use separate PIAs for public internet users?
> If so where are those PIAs located? (in the DMZ)?
> Do you have a load balancer? If so, how many and where are they
> And how do you handle authentication?
> Is there anything you would do differently if you had the
> If you don't feel happy sharing this information in public please write to
> me directly. All responses will be treated in confidence.
> David Kurtz
> Go-Faster Consultancy Ltd.
> tel: +44 (0)7771 760660
> fax: +44 (0)7092 348865
> web: www.go-faster.co.uk
> Book: PeopleSoft for the Oracle DBA: http://www.psftdba.com
> DBA Blogs: PeopleSoft: http://blog.psftdba.com, Oracle:
> PeopleSoft DBA Forum: http://groups.yahoo.com/group/psftdba