Additional params through ExternalAuthn LoginHandler

[Cantor, Scott]

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