Joint SP configuration for two applications- attributePrefix conflict

[Alexander Ivanov]

Thank you for your advice guys.

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.  It
would be much better if this round-trip was done behind the scenes, so that
our two applications can seamlessly function as one and users are not
confused by having to click Login multiple times.  I am not sure exactly
how to accomplish this.. is there any way to make the Shibboleth IdP create
session cookies for both subdomains whenever an IdP user logs in?

Scott, you mentioned "manipulating the cookie to live on a shared domain."
Could you please elaborate on what this entails and whether or not it could
help in our case?

I suppose if Shibboleth cannot generate a shared cookie that would be
readable by both applications, I can code each application to generate such
a shared cookie to serve as a flag every time IdP authentication takes
place.  So then when the user logs into Site A (through Shibboleth) and
then navigates to Site B, Site B can check for the existence of this shared
cookie and if it exists, automatically make the round-trip to the IdP so
that authentication for Site B can be done behind the scenes.

Please let me know what you guys think would be the best solution here.
Thanks again.

On Mon, Nov 21, 2016 at 5:24 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 11/21/16, 5:02 PM, "users on behalf of Alexander Ivanov" <
> users-bounces at shibboleth.net on behalf of alex at calmforce.com> wrote:
>
> > We have two applications running on the same domain (different
> sub-domains) that both need to be protected
> > by Shibboleth authentication.  The goal for the Shibboleth configuration
> is to allow for Single Sign On between
> > the two applications (user enters credentials once and gains access to
> both sites).
>
> If they're separate applications, really and truly, they should have
> separate entityIDs. That's simply a matter of policy and the whole point of
> how naming is done in SAML. SSO is up to the IdP and in most cases will be
> automatic and seamless, not something you need to be dealing with.
>
> But at least with Shibboleth, unless you're manipulating the cookie to
> live on a shared domain, each application will issue its own host-only
> session cookie and you're going to round-trip to the IdP anyway. This is
> true regardless of whether there's one entityID or two. There may be one
> application ID in the SP but the rule is that each application ID gets its
> own cookie. There is no rule that says there can only be one cookie per
> application ID.
>
> > Considering this, is a Shared Entity SP configuration possible?  Or do I
> need to configure our SP to use individual
> > entity IDs for Drupal and Dataverse, so that the configuration for these
> two resources can be different- one with
> > an attributePrefix and one without?
>
> I don't know what a "shared entity SP configuration" is, unless you just
> mean sticking multiple vhosts behind an entityID. That is allowed, but you
> should use separate entityIDs because it's the right thing to do if you
> have two unrelated applications, not because you have to.
>
> If you are the only IdP involved, then of course this is academic. You
> ultimately control both ends and the policy distinctions may not matter. In
> that scenario, you can do whatever you want, but it doesn't change how the
> cookies work.
>
> -- 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/20161123/c32cacc0/attachment.html>