Shib login in pop-up browser window?

[Eric Goodman]

I asked this in a recent thread (with no conclusive answer), and haven't had a chance to test yet. Perhaps you have...

Do you know if suppressing the UI (isPassive=True) would still generate this error authenticating within an iframe? I suspect yes, but was wondering if you have more direct evidence from your recent experience.

--- Eric


From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Michael A Grady
Sent: Wednesday, October 15, 2014 5:29 PM
To: Shib Users
Subject: Re: Shib login in pop-up browser window?


On Oct 15, 2014, at 2:39 PM, David Bantz <dabantz at alaska.edu<mailto:dabantz at alaska.edu>> wrote:


Following up, the vendor has corrected their description of what they are doing to state they are issuing the SAML request in an iframe.
I take it the IdP log message
WARN...No login context available, unable to proceed with authentication
reflects that inability to use cookies in the iframe.

Thanks to Mike and Scott's hints that the vendor was using frames, I found an interesting if ultimately inconclusive thread from 2008 which I relayed to the vendor.


There are techniques one can use to make this "mostly" work in an iFrame, if one really, really had to, but as noted, for any number of reasons, it's best to avoid/not support if you have any choice. (I've been working on an engagement where I've had to make some things work with an iFrame, because there wasn't a choice, which is the reason I have very recent experience with iFrames.) If you add a P3P header, you can get IE to accept the cookies in an iFrame. But then you actually need to have organizational policy behind that P3P header, and campus policy is hard work. (And you'd need to get all the pages that the IdP presents that write out a cookie to include said P3P header, which would be an effort in itself.) And with Safari, it will accept them (at least in my testing) as long as it already has a cookie from the domain being presented in the iFrame. So one could craft a special error page that presented a link to a page that  wrote out essentially a "no-op" cookie, just to have one there. And, of course, you're counting on browser behavior to not change and break one of these "work-around" strategies.

So opening a new page is definitely the way to go. The vendor can then do things to auto-close that page after the user completes the login.

--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20141016/6a438687/attachment-0001.html