<div dir="ltr">Thanks again for your time and help Scott. I may have talked the stakeholders into making the www site an SP that gets authenticated against the IdP. <div><br></div><div>If that doesn't happen.... is there anything that would prevent me from accessing a domain level cookie within my servlet?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 29, 2014 at 12:37 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 7/29/14, 1:23 PM, "snekse" <<a href="mailto:snekse@gmail.com">snekse@gmail.com</a>> wrote:<br>
><br>
>You state that "any information in the request to the IdP is accessible<br>
>from the login context via the API". Looking at the API,<br>
>loginContext.getProperty seems to be the only thing that would make sense<br>
>of where I might pull request information. (1.) Would the original<br>
>request params be in here?<br>
<br>
</div>No. The SAML information in the request is spread out across many<br>
different properties, and for a SAML 2 request, the Saml2LoginContext<br>
subtype contains the rest. An unsolicted request is turned into a mock<br>
SAML 2 AuthnRequest internally to unify the way the code interacts.<br>
<br>
There is nothing you can access that isn't part of the incoming request or<br>
the environmental settings of the IdP itself, and SAML expressly disallows<br>
passing other information via bindings. The way you get other information<br>
in is via SAML extensions inside the message itself. That doesn't work for<br>
Unsolicited, but it can be done by mocking up real SAML requests and<br>
sending them into the IdP.<br>
<div class=""><br>
>If I added a 'target' param to my /idp/profile/SAML2/Unsolicited/SSO<br>
>request, it seems like that gets saved off as the relayState for user<br>
>later when building the SAML message.<br>
<br>
</div>It does, yes.<br>
<div class=""><br>
> I could embed the key param into the relayState, but I wouldn't want to<br>
>pass that to the SP. (2.) Is there a way to extract the relayState, then<br>
>alter it for the duration of the request?<br>
<br>
</div>I don't think so. There's no setter, so I would assume that means it's not<br>
changeable.<br>
<div class=""><br>
>As I slowly start drifting away from the "correct" solution... a filter<br>
>seems like an option. Before the redirect, alter the redirect URL to<br>
>append the 'key' param. Despite making my skin crawl, a hack solution is<br>
>better than no solution.<br>
<br>
</div>We have a different opinion about that.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>