Joint SP configuration for two applications- attributePrefix conflict

[Alexander Ivanov]

Thanks guys.

Scott, I've tried the passive login approach.  It seems to work for the
Drupal site, but it fails for Dataverse.  So, when a user starts at the
Dataverse site, authenticates with the IdP, then navigates to the Drupal
site, and then a call is made to [Drupal
domain]/Shibboleth.sso/Login?isPassive=1, the user is properly logged into
the Drupal site.  However when I attempt to do the same thing by first
logging into the Drupal site and then navigating to Dataverse, making a
call to [Dataverse domain] /Shibboleth.sso/Login?isPassive=1 does create an
SSO session for the Dataverse domain, but *does not* log the user into the
Dataverse site.

I've created a thread in the Dataverse Google Group about Shibboleth
passive login support:
https://groups.google.com/forum/#!topic/dataverse-community/Fc0wC4fLyeI

The response I got was:
"I've never heard of this passive login feature of Shibboleth. It sounds
nice, and it sounds like what single sign on promises, which is the ability
to log in once and then be logged in to various applications such as
Dataverse and your Drupal application. It's not clear to me what changes
would need to be made to the Shibboleth Service Provider (SP) configuration
or to the Dataverse application itself, if any, but if you can figure it
out and create a pull request, we could test it and make sure it doesn't
break anything."

What changes would likely be necessary to make passive login work for
Dataverse?  Would it just be changes to the SP configuration, or would the
application code need to be modified?  If the latter is true, then this
approach would probably involve too much time/effort.

I think that I could still use the passive login approach to log the user
into the Drupal site, if the user authenticates with Dataverse first.
And when the user authenticates with Drupal first, I could create a custom
shared cookie to flag that authentication has occurred.  If the user then
navigates to the Dataverse site with the shared cookie, Dataverse can make
a call to /Shibboleth.sso/Login to (overtly) re-authenticate the user for
Dataverse.  Alternately, I can forgo making the shared cookie and just
leave the user logged out of Dataverse until he/she requests to access a
protected resource.


On Fri, Nov 25, 2016 at 11:45 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 11/23/16, 10:15 PM, "users on behalf of Alexander Ivanov" <
> users-bounces at shibboleth.net on behalf of alex at calmforce.com> wrote:
>
> > So, the host-only session cookies present a challenge.  Our two sites
> are on the same host, different subdomains.
> > Our ultimate goal is that when the user logs into Site A (through
> Shibboleth) and then navigates to Site B, Site B
> > recognizes that the user was previously authenticated and the user does
> not have to click Login again to make
> > the round-trip to the IdP.
>
> One way you haven't looked at is IsPassive. If you wanted to, your
> application could issue a passive login request to the IdP and if the
> user's already logged in, it will be seamless. With the Shibboleth SP,
> that's just a simple redirect to /Shibboleth.sso/Login?isPassive=1
>
> Personally I think that's better than shared cookies, and I know it's
> better than building a whole other layer of SSO into the system, but it's
> your choice.
>
> -- 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/20161128/fb48d5ac/attachment.html>