Modify forceAuthn Authentication Engine Behavior

Paul Hethmon paul.hethmon at clareitysecurity.com
Thu Dec 15 20:19:05 GMT 2011


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


>   Any feedback on this? I will even take "Are you freaking crazy!?!?".
>Just want to make sure technically this will remove all traces of the
>previous session and generate a whole new session. I am aware this could
>cause problems with SPs that assert isPassive but I do not believe I
>have any SPs that are asserting that currently. I can see no other way
>to solve this problem besides turning down the IdP's session length very
>low or setting up another IdP for these kinds of SPs. Neither of those
>approaches is appealing as it impacts every user that interacts with the
>IdP instead of just the ones that use the kiosk app. Any input is
>appreciated even flame.

John,

I think that will work, just speaking as someone who has tweaked that file
on a few occasions.

I'm just wondering if that really is easier than deploying another IdP
instance? Why not just zip up your current instance, unzip it somewhere
else, kill the sessions and modify the entityID of the server?

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.

So now you set that kiosk app to use the new IdP. Whenever you update the
IdP, follow the same process.

Even if you don't do that, you will have to set up a test one with your
code changes, so that work is committed.

Paul



More information about the dev mailing list