Bug in SP evaluation of nested Path statements?
cantor.2 at osu.edu
Tue Jan 10 00:30:41 GMT 2012
On 1/9/12 6:09 PM, "Michael W. Brogan" <mbrogan at u.washington.edu> wrote:
>Thanks for the help. The reason for the application override is to force
>a user with an existing session back to the authentication system to
>challenge them for a second factor (hw token in this case) when they
>either request a confidential resource or
>they attempt a privileged operation such as impersonation of another user
>in an app. Maybe there are better ways to do this, but this method has
>been working so far.
I realized that from the names after I posted that.
Unless you're triggering the session manually, the problem is step-up from
an existing session, which a single application won't allow. Using the
override creates the artificial session boundary that guarantees the IdP
gets involved again.
One improvement is to eliminate the extra SessionInitiator config and just
put the authnContextClassRef setting into the RequestMap wherever it
applies. That's less config machinery with the same result.
More information about the users