<div dir="ltr"><div><div>>   resolutionContext.getParent().getSubcontext("....AuthenticationContext").getAuthenticationResult()<br><br>Thanks Brent and Scott the above worked.   I think I'm on the right path I can now access the subject from javascript.  Scott, the background info you gave was also very helpful in understanding the limitations.<br><br></div></div><div>The issue I'm still having is my custom principal set in my external auth plugin isn't there, I think its being overwritten and I need to set the shibboleth.authn.External.addDefaultPrincipals option to False - which isn't in a released version of the IDP yet.  Do you have a release date scheduled for 3.2?    Do  you have any nightly built war files, otherwise I'll try building from the trunk.<br><br>>In general you don't, because it's not a valid thing to be passing data from authentication into the resolver, those aren't always running<br>
together. It generally means there's a problem in the design.<br><br>My
 external auth plugin includes a SAML SP - so I need a way to copy some of the
 attributes across to re-assert.   They might not even exist in a local 
directory or any place I can access them from my IDP.<br><div><div><br></div><div>-Topher<br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 3:48 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"><span class="">On 6/3/15, 8:16 PM, "cneberg" <<a href="mailto:cneberg@gmail.com">cneberg@gmail.com</a>> wrote:<br>
<br>
<br>
<br>
>How do I pass custom data in shibboleth 3?<br>
<br>
</span>In general you don't, because it's not a valid thing to be passing data<br>
from authentication into the resolver, those aren't always running<br>
together. It generally means there's a problem in the design.<br>
<br>
Assuming you don't care about queries and confine yourself to the front<br>
channel, you can add any Principals to the authentication result you want<br>
if you're using the External login method, otherwise you don't get that<br>
control generally speaking.<br>
<br>
Assuming you are using External, or are using a custom flow you created,<br>
you would need to retrieve the authentication information essentially the<br>
way Brent said, it's hanging off the ProfileRequestContext.<br>
<span class=""><br>
>getUserSession is no longer avaiable.<br>
<br>
</span>Sessions themselves are explicitly optional now (they can just be toggled<br>
off), so even on the front channel you would not want to build a script<br>
that assumes a session exists. The authentication result for a given front<br>
channel SSO profile execution can be accessed via AuthenticationContext,<br>
even when a session isn't actually being created to preserve it.<br>
<br>
There aren't any other scenarios except for SSO profiles where a result<br>
like that can be assumed.<br>
<span class=""><br>
>I've tried these methods instead to get to the subject but they all<br>
>return null.<br>
<br>
</span>resolutionContext is not the root of the tree. I believe the bug fixing<br>
the population of the profileContext variable is only fixed in trunk, but<br>
resolutionContext.getParent() will return it for now.<br>
<br>
So the AuthenticationResult associated with a front-channel request (there<br>
isn't such a thing for a query) is:<br>
<br>
resolutionContext.getParent().getSubcontext("....AuthenticationContext").ge<br>
tAuthenticationResult()<br>
<span class="HOEnZb"><font color="#888888"><br>
<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>
</font></span></blockquote></div><br></div>