Joint SP configuration for two applications- attributePrefix conflict

[Alexander Ivanov]

Hi Nate,

Thanks a lot, I think I'm starting to get a more clear picture of what to
do..

> You ultimately want login for one application to effect login for the
other application.  That, to me, smells like "looks like one application to
the IdP".
Correct.
>Do you have any use cases where the IdP could want to distinguish between
these two pieces?  Sending different attributes, trusting only one site,
etc.?
No. I would like them to look like one application to the IdP

> If not, then I would pursue the common entityID approach you've been
using.
Yes, this seems to make the most sense.  I tried the approach with one
entityID and it didn't work because of the attributePrefix conflict.  I
then attempted the configuration with two entity IDs, which worked
successfully, but created the problem described in my previous post.

I think that I need to go back to the common entityID approach, and just
find a way to maneuver around the attributePrefix problem.  You had
previously suggested:
> You can change AJP to pass through other attributes, *set multiple
attributes in the SP from a single SAML attribute with attribute-map.xml*,
turn on header variables for the AJP implementation..

I think what would make the most sense to me is *setting multiple
attributes in the SP from a single SAML attribute with attribute-map.xml*.  If
I can resolve the attributePrefix issue with attribute-map.xml mappings,
and both my applications will be covered under one entityID, then will the
user only need to authenticate through the IdP once to get access to both
applications?

On Wed, Nov 23, 2016 at 10:30 PM, Klingenstein, Nate <
nklingenstein at calstate.edu> wrote:

> Alex,
>
> > 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.
>
> This is something that federated identity generally doesn't do well
> because there is no central "hub" for everything, so there's nowhere to do
> this check on a large scale.
>
> You ultimately want login for one application to effect login for the
> other application.  That, to me, smells like "looks like one application to
> the IdP".
>
> Do you have any use cases where the IdP could want to distinguish between
> these two pieces?  Sending different attributes, trusting only one site,
> etc.?  If not, then I would pursue the common entityID approach you've been
> using.  If so, I would use a shim as described below.
>
> It's still very hard to give any advice without knowing the details here.
> All we can do is point you towards questions we think you should be asking.
>
> > 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?
>
> The IdP doesn't create session cookies for applications.  The IdP gives
> the user a SAML assertion payload that they deliver to the SP, at which
> point it's processed, consumed, and turned into a cookie-based session.
>
> You could rely on these cookies directly or as a bridge into another
> session persistence mechanism.
>
> > 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?
>
> You can explicitly set cookie properties at the SP:
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPCookieUsage
>
> > 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.
>
> You could do it in a thousand ways.  A shared cookie is one option.
>
> This remoting of identity is basically what SAML was designed for, so
> you're effectively doing a second layer of federated identity if you want
> to have a shim or your own layer.  That's not to say it's a bad idea, but
> you should think of it as another SSO protocol, ish.
>
> > Please let me know what you guys think would be the best solution here.
> Thanks again.
>
> It remains personal preference, in my eyes.  If this should really be seen
> always as 1 combined application, then I would set cookies that will be
> legible to both A and B using cookieProps, but there are many ways to skin
> this potato.
>
> Hope this helps, and thanks for taking the time to think deeply on it,
> Nate.
> --
> 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/4827076f/attachment-0001.html>