MCB "configuration" per SP

[Scott Koranda]

On Fri, Apr 17, 2015 at 12:25 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 4/17/15, 1:18 PM, "Scott Koranda" <skoranda at gmail.com> wrote:
>
>>The mechanism described above would allow for a per-SP/per-user
>>"configuration", though admittedly it is not particularly elegant.
>>
>>Am I missing something? It appears to work well with my sandbox.
>
> I believe that approach was suggested in another thread this week or last as the way to accomplish that. It hadn't been totally confirmed on list that it worked, but it sounds like it does.
>

No, I see what I was missing after reviewing that thread and the code.

Paul Hethmon wrote it this way:

"When MCB handles previous session (which it should), the context value it has \
available to determine what to do is from the last successful
authentication. So if \
the previous allowed value matches what the user has used, then
previous session \
handling takes place and there is never another call to the attribute resolver."

Put another way, the attribute resolution that the MCB does to
determine the allowed contexts for the user does not fire if the user
already has a session with the MCB, the MCB is configured with
previousSesssion="true", and the SP has not requested a context.

A MCB submodule that handles SSO itself so that previousSession can be
set to "false" will allow the attribute resolution code to fire. But
if the MCB is handling SSO then the attribute resolution only happens
once and the allowed contexts returned at that time will be used again
later no matter the SP if the SP has not requested a context (referred
to as 'Case 1' in the code today).

Thanks,

Scott K