<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>In addition to what others have written:...</div>
<div><br>
</div>
<div>Its generally considered best practice to have a webserver in front of tomcat in a production environment, as it means you can have the webserver serve up static content (and have an easier job setting caching rules), which takes the load of Tomcat and
makes things generally makes for quicker load times. Similarly, it gives you a place to configure things like HTTP connection reuse.</div>
<div><br>
</div>
<div>Its easier to find <b>operational</b> skills in Apache (whereas in my experience Tomcat skills are closer to a
<b>developer</b> role)</div>
<div><br>
</div>
<div>You may often have another operational desire to serve up content from the machine, such as for performance management and monitoring (eg. you might have a /statistics/ path that serves up some local content that you produce from a script. I find this
is be invaluable, also because I can get Apache to use a more custom logging format that includes, amongst other things, service time, and where things were actually redirected to, etc. etc. I don't know how to do this in Tomcat... assuming its possible.</div>
<div><br>
</div>
<div>Note: The IdP's logs (as distinct from Tomcat's logs), are also useful for monitoring, but if you want to use the process logs, I strongly suggest that you change the logging format for the timestamps.</div>
<div><br>
</div>
<div>Being able to use Apache modules to handle authentication is very useful (in relation to the RemoteUser IdP authentication method), particularly where you need to inter-operate with an existing SSO system (such as many proprietary systems, or systems such
as CAS, ....). As another aside, for load-testing, you could conceivably use Apache's rewrite logic (or a custom module, which is easier than you think) to set REMOTE_USER to something particular: this makes things like Apache JMeter testing scripts
<b>much</b> easier to write (although I haven't done this for Shibboleth, I have done this with other SSO systems).</div>
<div><br>
</div>
<div>Hope this helps.</div>
<div>Cameron</div>
<div><br>
Cameron Kerr. Sent from my iPad.
<div>Systems Engineer, Systems Services Team, ITS, Otago University</div>
</div>
<div><br>
On 1/02/2014, at 2:15 am, "Craig Caughlin" <<a href="mailto:craigcaughlin@gmail.com">craigcaughlin@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>If I understand it correctly, for a "basic" Shibboleth idP server, you don't need a web server like IIS or Apache - Tomcat will work just fine.<br>
<br>
Which kind of begs the question...under what circumstances WOULD you want or NEED to have a web server application in use on your idP server?<br>
<br>
</div>
<div>I'm trying to plan for the future in the implementation of our Shib server and, hopefully, not have to configure it twice!<br>
<br>
:-)<br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>--</span><br>
<span>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">
users-unsubscribe@shibboleth.net</a></span></div>
</blockquote>
</body>
</html>