Correlating custom login with existing session from different login type

[Cantor, Scott]

On 10/12/14, 3:17 PM, "Byte Flinger" <byteflinger at gmail.com> wrote:

>I am trying to get a sense of how much work would it be to write a
>different custom login module (For example sending a token which is
>looked up in a database) so that a user can login via either module and
>switch to the other afterwards without losing his existing session.

Sorry, I don't understand what that means. If you add a login hamdler,
then which one gets used is dependent on a lot of factors that are
explained in the wiki, but in V2 you get one shot, one handler runs, and
it either works or it doesn't.

Sessions have nothing to do with that process. The session is at a
different layer, higher than all that, and it records a record of which
handler was used and how long its results remain active for reuse.

>My guess is, for starters, I'd need to write a custom login handler to
>get the login module working however I am uncertain how would I go about
>making it somehow correlate with the user existing session from the other
>other login module (in this case a username/password login) so SSO still
>works.

You don't. If you use the IdP's session mechanism and the PreviousSession
handler, then SSO is handled outside of the login handlers entirely,
they're oblivious to it. They run when SSO doesn't happen.

>Any input would be appreciated. I am mostly trying to understand how much
>work would this take and should it not prove too complicated, how to
>roughly go about it.

I don't really understand what you asked about doing, so I'm just
answering what I can. The basic answer is that if you're trying to do
anything substantially complex, you will probably have to read and
understand all of the authentication code to have any shot at not opening
a hole.

None of this translates to V3 BTW, that's completely rewritten code with
no compatibility whatsoever in buiding login handlers.

-- Scott