<div dir="ltr"><div>Hi Nate,</div><div><br></div><div>Thanks a lot, I think I'm starting to get a more clear picture of what to do..</div><div><br></div><div>> 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".</div><div>Correct.<br>>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.? </div><div>No. I would like them to look like one application to the IdP</div><div><br></div><div>> If not, then I would pursue the common entityID approach you've been using.</div><div>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.</div><div><br></div><div>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:</div><div>>  You can change AJP to pass through other attributes, <b>set multiple attributes in the SP from a single SAML attribute with attribute-map.xml</b>, turn on header variables for the AJP implementation..</div><div><br></div><div>I think what would make the most sense to me is <i>setting multiple attributes in the SP from a single SAML attribute with attribute-map.xml</i>.  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?  <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 23, 2016 at 10:30 PM, Klingenstein, Nate <span dir="ltr"><<a href="mailto:nklingenstein@calstate.edu" target="_blank">nklingenstein@calstate.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alex,<br>
<span><br>
> 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.<br>
<br>
</span>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.<br>
<br>
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".<br>
<br>
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.<br>
<br>
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.<br>
<span><br>
> 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?<br>
<br>
</span>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.<br>
<br>
You could rely on these cookies directly or as a bridge into another session persistence mechanism.<br>
<span><br>
> 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?<br>
<br>
</span>You can explicitly set cookie properties at the SP:<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPCookieUsage" target="_blank" rel="noreferrer">https://wiki.shibboleth.net/<wbr>confluence/display/SHIB2/<wbr>NativeSPCookieUsage</a><br>
<span><br>
> 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.<br>
<br>
</span>You could do it in a thousand ways.  A shared cookie is one option.<br>
<br>
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.<br>
<span><br>
> Please let me know what you guys think would be the best solution here.  Thanks again.<br>
<br>
</span>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.<br>
<br>
Hope this helps, and thanks for taking the time to think deeply on it,<br>
Nate.<br>
<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.<wbr>net</a><br>
</div></div></blockquote></div><br></div>