Correlating custom login with existing session from different login type

[Byte Flinger]

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

I will try to gather more concrete information before returning on the
subject.

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?

Regards
Byte
On 12 Oct 2014 21:45, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> 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
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20141012/6bae202f/attachment.html