Pass dynamic properties from SP to IdP?

[Brian Reindel]

The HttpServletHelper has access to the login context, and that
Saml2LoginContext implementation does have a getter for the
AuthnRequest. However, it sounds like without a custom AuthnRequest
with a "parameters node" though it just isn't possible. Our SPs and
IdP are on the same primary domain, so I may just end up setting a
cookie to pass the additional data. If you do have a link describing
how to create a custom AuthnRequest I would still be interested in
reading up on it.

Use Case:

Some users have a desktop application installed that has stored their
username/password encrypted using public/private key encryption. That
application launches a browser and posts to an SP endpoint with
passive protection with this encrypted data. This endpoint redirects
to the SessionInitiator endpoint, and that encrypted data then needs
to make its way from the SP to the IdP. Our external authentication
handler will then decrypt it with the private key, auto-login the
user, call AuthenticationEngine#returnToAuthenticationEngine, and then
the user will be redirected to the target URL passed to the
SessionInitiator. The user will then be able to use the other web
applications in our enterprise without logging in again. The trick is
getting that encrypted data over to the IdP so that a SSO session can
be created.

I'm open to other ways of doing this, but based upon our use case I
can't think of another way to get us an authenticated session in this
scenario.

Thanks,


On Tue, Sep 3, 2013 at 2:48 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 9/3/13 2:21 PM, "Brian Reindel" <brian at reindel.com> wrote:
>
>>I have some dynamic information I would like to pass from the SP to
>>the IdP for use during external authentication. I can't find anything
>>that would allow me to do this. Is this possible, and if it is, can
>>those properties be accessed in the external authentication servlet I
>>create on the IdP?
>
> That's not permitted in SAML except by means of an extension to the
> AuthnRequest. I don't know for certain that the servlet in that particular
> instance has access to the request message either but if it has access to
> the LoginContext managed by the IdP during the process, it would.
>
> In any case, this is a very complex thing to do and is best avoided, but
> it's theoretically possible.
>
> Since there's very little use of the complexity of the protocol as it is,
> I would be interested to know what the use case is.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net