<div dir="ltr">Hi!<br><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra">Thank you for all answers, maybe it will give me some new arguments to convince client to change requirement and use standard solution.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
Best Regards</div><div class="gmail_extra">Pawel<br><br><div class="gmail_quote">2014-05-07 10:29 GMT+02:00 Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span>: M<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Paweł Pogoda <<a href="mailto:paw.pogoda@gmail.com">paw.pogoda@gmail.com</a>> [2014-05-07 09:51]:<br>
<div class="">> Basically what I do here is before posting user/password data to IdP<br>
> servlet I create iframe with URL to <a href="http://www.localhost.com" target="_blank">www.localhost.com</a> (portal1)<br>
> private page which I want to access (this create login context in<br>
> IdP).<br>
<br>
</div>Which will break when people have third-party cookies disabled in<br>
their browsers, as Scott already pointed out (and what I fully<br>
recommend to anyone). Or if the IDP had the HttpOnly flag on the<br>
cookie used for tracking the login context.<br>
<br>
There is no "authentication API" for the Shibboleth IDP.<br>
<br>
Maybe you'll want a different product. But I guess you'll generally<br>
find little support for misleading users on purpose wrt the service<br>
where their credentials are actually sent to.<br>
<br>
The "requirements" you have been given are usually dealt with by<br>
changing the applications (here "client1") to only include a Login<br>
link or button (which in your case would probably be a link to the<br>
protected resource on the "portal"), possibly together with branding<br>
the IDP login page appropriately.<br>
Note that from what you wrote the IDP cannot brand the login page<br>
according to "client1", but only based on the SAML SP for which it<br>
recieved the authentication request (which is "portal1" in your case,<br>
not "client1"). The resource/URL where you want the password prompt<br>
to appear isn't related to either the SAML IDP nor the SAML SP (i.e.,<br>
the protected resource), so it's not something the SAML IDP can know<br>
about. Not surprisingly SAML has not defined a role for what you want<br>
those pages to do.<br>
<br>
Other somewhat related way to do this is by actually performing<br>
authentication outside the IDP (not just pretenting to do so), and<br>
creating a session in the Shibboleth IDP via the ExternalAuthn login<br>
handler.<br>
But that doesn't suite your "requirements" either, IMO.<br>
<span class="HOEnZb"><font color="#888888">-peter<br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a></div></div></blockquote></div><br></div></div>