Additional params through ExternalAuthn LoginHandler

[snekse]

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.

If that doesn't happen....  is there anything that would prevent me from
accessing a domain level cookie within my servlet?


On Tue, Jul 29, 2014 at 12:37 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 7/29/14, 1:23 PM, "snekse" <snekse at gmail.com> wrote:
> >
> >You state that "any information in the request to the IdP is accessible
> >from the login context via the API".  Looking at the API,
> >loginContext.getProperty seems to be the only thing that would make sense
> >of where I might pull request information. (1.) Would the original
> >request params be in here?
>
> No. The SAML information in the request is spread out across many
> different properties, and for a SAML 2 request, the Saml2LoginContext
> subtype contains the rest. An unsolicted request is turned into a mock
> SAML 2 AuthnRequest internally to unify the way the code interacts.
>
> There is nothing you can access that isn't part of the incoming request or
> the environmental settings of the IdP itself, and SAML expressly disallows
> passing other information via bindings. The way you get other information
> in is via SAML extensions inside the message itself. That doesn't work for
> Unsolicited, but it can be done by mocking up real SAML requests and
> sending them into the IdP.
>
> >If I added a 'target' param to my /idp/profile/SAML2/Unsolicited/SSO
> >request, it seems like that gets saved off as the relayState for user
> >later when building the SAML message.
>
> It does, yes.
>
> > I could embed the key param into the relayState, but I wouldn't want to
> >pass that to the SP.  (2.) Is there a way to extract the relayState, then
> >alter it for the duration of the request?
>
> I don't think so. There's no setter, so I would assume that means it's not
> changeable.
>
> >As I slowly start drifting away from the "correct" solution... a filter
> >seems like an option.  Before the redirect, alter the redirect URL to
> >append the 'key' param.  Despite making my skin crawl, a hack solution is
> >better than no solution.
>
> We have a different opinion about that.
>
> -- 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/20140729/a27b55b6/attachment.html