Portal - Internal or External?
Adam_Dzyacky
Product Owner Contributor Monkey ✭✭✭✭✭
I'm curious what other's organizations/clients feelings are around the portal being externally facing. I know several security folks who seem slightly terrified at the idea of exposing the portal (not because of Cireson, but because of the data SCSM exposes based on the user) but equally recognize it's potential to be leveraged for a host of requests as well as Asset Management.
What's more, if do you have an internal/external facing deployment (and of course without sharing hostnames) - what does your topology look like? I can think of a few but again, curious what kind of variations exist between deployments that leverage the Cireson Portal.
For example:
What's more, if do you have an internal/external facing deployment (and of course without sharing hostnames) - what does your topology look like? I can think of a few but again, curious what kind of variations exist between deployments that leverage the Cireson Portal.
For example:
- 1 WF server, 2 mgmt servers and those 2 management servers host the portal that is accessible internally and externally
- 1 WF, 4 mgmt servers. 2 for internal and 2 for external
- 1 WF/mgmt server that handles internal and external
2
This discussion has been closed.
Comments
More specifically an IIS question I'm getting at (as a follow up to my previous examples) is do you (Cireson) or anyone here utilize two Portals on IIS one for internal/external? Again, just curious what various deployment topologies looks like.
We are using the first example setup for both internal\external
- 1 WF server, 2 mgmt servers and those 2 management servers host the portal that is accessible internally and externally
Can send you some more information around reference architecture if your interested let me know.Cheers
Joe
It is possible to run two portal websites on one IIS box but i wouldn't recommend this in production. My recommendation for a large enterprise where Cireson portal is pretty critical for business processes is to have two Web Servers (load balanced) for internal Portal. These are configured to use Windows Auth as internal clients will support this. Then, to have a further two Web Servers (also load balanced) for the external Portal. These are configured to use Forms Auth to allow any client to connect from the outside and this means they do not have to be SCSM Management Servers which helps with security if needed.
If this is overkill, then just 1 Web Server for each, but I still think its useful to keep internal and external separate or authentication, security and troubleshooting.
Finally, I always recommend that if you do adopt this scenario, to use dual DNS. So you internal clients will resolve portal.contoso.com to the internal server(s) and external public DNS servers will resolve portal.contoso.com to the external server(s). This allows clients to roam between internal and external and all links, favourites, history etc will still work.
Geoff
//F
Resurrecting this old thread to see what others has done since this thread many moons ago. I too am curious see some reference architecture.
I am eyeing the middle approach with 2 external and 2 internally facing servers.
Cheers
With that said, I'm having issues with UAG blocking our Cireson portal components right now and once I figure out why, I hope to share the settings needed with the Cireson community if anyone else uses UAG.
Are you able to send over the architecture your referring to at all?
Cheers!