Login box (embedded in external portals outside IdP)

Peter Schober peter.schober at univie.ac.at
Wed May 7 04:29:55 EDT 2014

* 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
But that doesn't suite your "requirements" either, IMO.

More information about the users mailing list