<p dir="ltr">Thanks Cantor. To be honest since I don't understand the Shibboleth process for SSO into too much detail I am probably talking a bit gibberish.<br>
I guess what I mean for now is if there a way for the user to login with the LDAP login handler (Unsolicited SSO) and later on login through a different custom handler and have a SAML response be received that is bound to the same relying party as the one bound to the original ldap login request. I believe you can configure more than 1 login handler for a relying party (right?) however the issue in this case would be how to handle attributes which are, when requesting through the ldap login handler, retrieved from the LDAP server since I no longer have the username/password to perform an LDAP lookup. Maybe configure a general user use to lookup other users in the database?</p>
<p dir="ltr">I will try to gather more concrete information before returning on the subject.</p>
<p dir="ltr">I am aware that Shibboleth 3.0 has different code but you speak as if the release is imminent. Do we have a release date on it already?</p>
<p dir="ltr">Regards<br>
Byte</p>
<div class="gmail_quote">On 12 Oct 2014 21:45, "Cantor, Scott" <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/12/14, 3:17 PM, "Byte Flinger" <<a href="mailto:byteflinger@gmail.com">byteflinger@gmail.com</a>> wrote:<br>
<br>
>I am trying to get a sense of how much work would it be to write a<br>
>different custom login module (For example sending a token which is<br>
>looked up in a database) so that a user can login via either module and<br>
>switch to the other afterwards without losing his existing session.<br>
<br>
Sorry, I don't understand what that means. If you add a login hamdler,<br>
then which one gets used is dependent on a lot of factors that are<br>
explained in the wiki, but in V2 you get one shot, one handler runs, and<br>
it either works or it doesn't.<br>
<br>
Sessions have nothing to do with that process. The session is at a<br>
different layer, higher than all that, and it records a record of which<br>
handler was used and how long its results remain active for reuse.<br>
<br>
>My guess is, for starters, I'd need to write a custom login handler to<br>
>get the login module working however I am uncertain how would I go about<br>
>making it somehow correlate with the user existing session from the other<br>
>other login module (in this case a username/password login) so SSO still<br>
>works.<br>
<br>
You don't. If you use the IdP's session mechanism and the PreviousSession<br>
handler, then SSO is handled outside of the login handlers entirely,<br>
they're oblivious to it. They run when SSO doesn't happen.<br>
<br>
>Any input would be appreciated. I am mostly trying to understand how much<br>
>work would this take and should it not prove too complicated, how to<br>
>roughly go about it.<br>
<br>
I don't really understand what you asked about doing, so I'm just<br>
answering what I can. The basic answer is that if you're trying to do<br>
anything substantially complex, you will probably have to read and<br>
understand all of the authentication code to have any shot at not opening<br>
a hole.<br>
<br>
None of this translates to V3 BTW, that's completely rewritten code with<br>
no compatibility whatsoever in buiding login handlers.<br>
<br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>