IDP-948

[Cantor, Scott]

Interested in feedback on this. The issue here is the one Lukas raised a while back, among others, the ability to set some of the common configuration options dynamically rather than with a static bean property triggered by a single RelyingParty override (so you don't need 100 overrides to implement a mapping table of RP->setting).

I considered a few ways, but the best seemed to be to try and do as much work as possible on our part and just add setters for Function<ProfileRequestContext,T> for every setting we support. The commit here implements this for the top level RelyingPartyConfiguration class's properties. If it's reasonable, I can get it implemented throughout all the ProfileConfiguration types and their numerous properties that aren't already dynamic predicates and functions.

The trick to this is we have inject our HttpServletRequest proxy and use Marvin's addition that puts the ProfileRequestContext into a request attribute with a flow listener. The normal accessors for these properties don't pass in the PRC at runtime, so I had to backdoor it.

The nice thing about this is none of the code in the IdP that accesses the various properties has to change, it just gets done internally in the existing configuration classes, so I think it's a decent approach.

Using this mechanism is pretty simple. If you wanted to apply a mapping function that derived the IdP's entityID based on SP entityID, you'd just plug the Function bean into a RelyingPartyConfiguration bean with p:responderIdLookupStrategy and that's it.

-- Scott

-----Original Message-----
From: commits [mailto:commits-bounces at shibboleth.net] On Behalf Of noreply at shibboleth.net
Sent: Thursday, March 10, 2016 10:44 PM
To: commits at shibboleth.net
Subject: [java-identity-provider COMMIT] in /trunk: idp-conf/src/test/java/net/shibboleth/idp/test/flows/SetupForResolver.java...

Author: scantor
Date: Thu Mar 10 22:43:41 2016
New Revision: 8148

URL: http://svn.shibboleth.net/view/java-identity-provider?rev=8148&view=rev