Custom Principal & Authentication Data Passing

[cneberg]

>
resolutionContext.getParent().getSubcontext("....AuthenticationContext").getAuthenticationResult()

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.

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.

>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
together. It generally means there's a problem in the design.

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.

-Topher

On Wed, Jun 3, 2015 at 3:48 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 6/3/15, 8:16 PM, "cneberg" <cneberg at gmail.com> wrote:
>
>
>
> >How do I pass custom data in shibboleth 3?
>
> 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
> together. It generally means there's a problem in the design.
>
> Assuming you don't care about queries and confine yourself to the front
> channel, you can add any Principals to the authentication result you want
> if you're using the External login method, otherwise you don't get that
> control generally speaking.
>
> Assuming you are using External, or are using a custom flow you created,
> you would need to retrieve the authentication information essentially the
> way Brent said, it's hanging off the ProfileRequestContext.
>
> >getUserSession is no longer avaiable.
>
> Sessions themselves are explicitly optional now (they can just be toggled
> off), so even on the front channel you would not want to build a script
> that assumes a session exists. The authentication result for a given front
> channel SSO profile execution can be accessed via AuthenticationContext,
> even when a session isn't actually being created to preserve it.
>
> There aren't any other scenarios except for SSO profiles where a result
> like that can be assumed.
>
> >I've tried these methods instead to get to the subject but they all
> >return null.
>
> resolutionContext is not the root of the tree. I believe the bug fixing
> the population of the profileContext variable is only fixed in trunk, but
> resolutionContext.getParent() will return it for now.
>
> So the AuthenticationResult associated with a front-channel request (there
> isn't such a thing for a query) is:
>
> resolutionContext.getParent().getSubcontext("....AuthenticationContext").ge
> tAuthenticationResult()
>
>
> -- 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/20150604/404f7442/attachment-0001.html>