Modify forceAuthn Authentication Engine Behavior

[Paul Hethmon]

On 12/15/11 4:04 PM, "John Mitchell" <jpmitchell at alaska.edu> wrote:


>>
>>I duplicate IdP instances all the time myself and that task is literally
>>just minutes. You would modify relying-party.xml, internal.xml, and
>>handler.xml in the conf directory and idp-metadata.xml in the metadata
>>directory. You could make it pretty simple and just change the entityID
>>by
>>adding something to it, so its a search and replace operation, from
>>"idp.alaska.edu" to "idp-kiosk.alaska.edu". Add the new hostname to DNS
>>and you're practically done.
>>
>
>    That sounds pretty easy. Is that hosted in the same Tomcat instance?
>Would you expand on this off list? I could see some ways this could work
>if I put the short session IdP on the same infrastructure as the
>existing IdP just at a different place in the URL name space. So maybe
>https://idp.alaska.edu/idp-kiosk for lack of a better URL.


I don't host in the same Tomcat instance, but I do host on the same server
(VM).

So, to conserve IP addresses, we run all of our Tomcat on non-standard
ports. So I would have something like this in my environment:

main idp:  tomcat https connector on port 10443

secondary idp:  tomcat https connector on port 11443

Then we do the port translation in our our Foundry 4G ServerIron load
balancer, though you could likely do it in a firewall or even Apache
fronting both servers.

If you terminate SSL in a network device, it likely can do the port
translation for you. So put this special instance on another port. Then
you've got 2 VIPs set up, each on a different IP.

But the key thing is once you set that up (the network infrastructure),
it's done. Any IdP update is simply the zip up and modify procedure, so
you don't really have to maintain multiple instances. You've got just an
incremental amount of work for the second instance.

Feel free to email me off list.

thanks,

Paul