OpenSAML how-to: adding transport to context

[Misagh Moayyed]

Thanks. Just reporting back that I got this all to work on the SP side. Still lots to do, but now I can somewhat make sense out of it :)

- Misagh

> On May 20, 2015, at 11:13 PM, Brent Putman <putmanb at georgetown.edu> wrote:
> 
> 
> 
> On 5/20/15 2:22 PM, Misagh Moayyed wrote:
>> Sure, but on the idp side, I am not finding anything that explicitly
>> defines the set of algorithms that are passed to that instance. Are they
>> retrieved from "shibboleth.DefaultSecurityConfiguration"?
> 
> Scott already described the general mechanism.  For each of the 4 cases of signing, validation, encryption and decryption, you pass 1 or more instances of a corresponding -Configuration into a -Resolver to produce a -Parameters instance.
> 
> Btw, the SAML Metadata-aware versions of the signing and encryption -Resolvers will also pull algorithm preferences from the peer's SAML metadata, if they are present present and as long as the relevant config whitelist/blacklist policy doesn't exclude them from consideration.
> 
> It's pretty sophisticated and flexible.  But all of that is decoupled from the contract you honor for purposes of the signing handler (and the other handlers).  All it cares about is that the -Parameters instance is in the MessageContext.  So you can populate that anyway you want.
> 
> 
>>  and in the code
>> deemed to be the same as signatureAlgorithms? 
> 
> No, those are only the signature/HMAC algorithms.  C14N has its own config and params slot called signatureCanonicalizationAlgorithm.
> 
>> 
>> I ask because "BasicSignatureSigningParametersResolver" requires those to
>> pass validate, and I am not seeing how they are set by the idp to begin
>> with. 
> 
> 
> You may not see the c14n algorithms explicitly declared in the IdP wiring, I don't remember.  Most of the config "slots" have OpenSAML library-wide defaults stored in global -Configuration instances available in the ConfigurationService (after initialization), so declaring them in the IdP is optional unless you want to override or make them explicit.  If you want to see what those default values are, look at DefaultSecurityConfigurationBootstrap in xmlsec-impl.  You can get at those global -Configuration instances easily with SecurityConfigurationSupport in xmlsec-api
> 
> 
> -- 
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net