Modify forceAuthn Authentication Engine Behavior

[John Mitchell]

Paul,

On 12/15/2011 11:19 AM, Paul Hethmon wrote:
> 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.
>

    Thanks for the review. I think I will move this to my test instance
and try it.

> 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?
>

     The time to get OS images in place, load balancer changes in place,
DNS name changes in place, and services in place (especially since I
would be dealing with multiple departments) would probably be weeks.
Also my management is not interested in the idea of having another IdP.
This is also a case of needing to meet project requirements that where
revealed very late in the implementation time line, so I cant wait too long.

> 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.

> 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.
>

   Quite so, but that test server is already in place and gets all
changes washed through it already.

> Paul
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net


-- 
John P. Mitchell <jpmitchell at alaska.edu>
907.450.8320
http://www.alaska.edu/oit/iam

"All mankind is divided into three classes: those that are immovable,
those that are movable, and those that move." - Benjamin Franklin