RelyingPartyOverrides

[Brent Putman]

On 3/24/15 1:36 PM, Michael O Holstein wrote:
> I suspect the answer to my question is along these lines ...
>
> [conf/credentials.xml]
> <!-- SHA1 credentials -->
>     <bean id= "SHA1SecurityConfig"
>         class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
>         p:privateKeyResource="%{idp.sha1signing.key}"
>         p:certificateResource="%{idp.sha1signing.cert}"
>         p:entityId-ref="entityID" />
>
> the path must be specified explicity somewhere because the keys/certs of those names are in the same location
>
> Could not resolve placeholder 'idp.sha1signing.cert' in string value "%{idp.sha1signing.cert}"; nested exception is java.lang.IllegalArgumentException: Could not resolve placeholder 'idp.sha1signing.cert' in string value "%{idp.sha1signing.cert}"
>


Yes, that's essentially how you'd define a new credential, which you'd
then reference in the signing config, except: Those property names
don't just magically exist.  You'd have to define them in a property
file somewhere.  But you really don't need to use full properties
there.  We use those to simplify and abstract out config for deployers,
but you can just put literal values there.  Or better, you might want
to make the path relative to idp.home and use a form similar to what
you see in idp.properties, e.g. "
%{idp.home}/credentials/custom-signing.crt".

But as I said previously, you certainly don't need to use a custom
credential just because you want to use SHA-1 signing algorithms. 
That's only necessary if the relying party in question is not a
Shibboleth SP and has some weird requirement/limitation that it won't
accept the default signing cert, e.g. perhaps because it's using a PKIX
trust model and has an older PKIX library that doesn't support SHA-256
certs. Or something like that.  Many SP's are going to use an "explicit
key" trust model however, where the cert algorithms are completely
irrelevant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20150324/b3a4dfe1/attachment.html