Problem configuring and IdP to support anonymous relying parties

[Brent Putman]

On 9/14/11 11:38 AM, Jon Warbrick wrote:

>
> 
> 16:10:16.540 - DEBUG
> [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:127]
> - Looking up relying party configuration for
> https://mnementh.csi.cam.ac.uk/shibboleth-xx
> 16:10:16.540 - DEBUG
> [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:133]
> - No custom relying party configuration found for
> https://mnementh.csi.cam.ac.uk/shibboleth-xx, looking up configuration
> based on metadata groups.
> 16:10:16.541 - DEBUG
> [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:156]
> - No custom or group-based relying party configuration found for
> https://mnementh.csi.cam.ac.uk/shibboleth-xx. Using default relying
> party configuration.
> 


Looking at the code, I think what you are seeing is currently
"expected", although obviously not correct.  The way the security policy
is resolved happens very early, in the message decoding stage.  Btw, I
think the error conceptually exists on the front-channel SSO as well,
but you aren't seeing a failure there because there isn't usually any RP
authentication or strong security requirement on front-channel.

I think we have a bug here in either the
SAMLMDRelyingPartyConfigurationManager or possibly the
RelyingPartySecurityPolicyResolver which makes use of it.

The RP config manager doesn't seem to strictly implement the definitions
for anonymous vs default vs custom RP's that are defined in the wiki[1].
(This discrepency is also reflected in its Javadocs). It doesn't
evaluate at all whether there is metadata for the entityID (except for
looking up EntitiesDescriptor groups).  If the intention is for this
component to return the "effective" RP config to be used, then this
seems wrong vis-a-vis these definitions.

On the other hand, if the intention is for the RP config manger to be
merely a lookup into the IdP config, and it's up to clients of the RP
manager to make the anonymous vs default vs custom distinction for the
effective config, then the security policy resolver is the culprit. (It
looks like the SAML profile handlers operate this way, making their own
anonymous RP evaluation based on presence/absence of metadata.  See
AbstractSAMLProfileHandler#getRelyingPartyConfiguration(String)).

I guess Chad will have to weigh in what what the behavior of the RP
config manager ought to be.

[1] https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnderstandingRP