Login box (embedded in external portals outside IdP)

[Paweł Pogoda]

Hi!

In my opinion solution with simple login link/button (here 'client1') would
be the best (standard way to handle it), we even try to convince client to
it but unfortunately without success. I hope that finally client will
understand that this is the way that it should be handled.
Thank you for all answers, maybe it will give me some new arguments to
convince client to change requirement and use standard solution.

Best Regards
Pawel

2014-05-07 10:29 GMT+02:00 Peter Schober <peter.schober at univie.ac.at>: M

> * Paweł Pogoda <paw.pogoda at gmail.com> [2014-05-07 09:51]:
> > Basically what I do here is before posting user/password data to IdP
> > servlet I create iframe with URL to www.localhost.com (portal1)
> > private page which I want to access (this create login context in
> > IdP).
>
> Which will break when people have third-party cookies disabled in
> their browsers, as Scott already pointed out (and what I fully
> recommend to anyone). Or if the IDP had the HttpOnly flag on the
> cookie used for tracking the login context.
>
> There is no "authentication API" for the Shibboleth IDP.
>
> Maybe you'll want a different product. But I guess you'll generally
> find little support for misleading users on purpose wrt the service
> where their credentials are actually sent to.
>
> The "requirements" you have been given are usually dealt with by
> changing the applications (here "client1") to only include a Login
> link or button (which in your case would probably be a link to the
> protected resource on the "portal"), possibly together with branding
> the IDP login page appropriately.
> Note that from what you wrote the IDP cannot brand the login page
> according to "client1", but only based on the SAML SP for which it
> recieved the authentication request (which is "portal1" in your case,
> not "client1").  The resource/URL where you want the password prompt
> to appear isn't related to either the SAML IDP nor the SAML SP (i.e.,
> the protected resource), so it's not something the SAML IDP can know
> about. Not surprisingly SAML has not defined a role for what you want
> those pages to do.
>
> Other somewhat related way to do this is by actually performing
> authentication outside the IDP (not just pretenting to do so), and
> creating a session in the Shibboleth IDP via the ExternalAuthn login
> handler.
> But that doesn't suite your "requirements" either, IMO.
> -peter
> --
> 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/20140507/8701a907/attachment-0001.html