Shibboleth Developers

[Brent Putman <>]

I've looked into this some more...  I initially misdiagnosed part of the
problem.

The error you're getting about "Illegal key size or default parameters"
is because it looks like you have not installed the Java JCE unlimited
strength jurisdiction policy files (I know Chad and I always do by
default, so we weren't seeing this...).  By default Sun's JRE only
allows use of AES keys (and most symmetric keys except triple DES) of
128 bits or less.  We're defaulting right now to AES-256 for the
auto-generated keys when we do data encryption.  Unless we want to
introduce the installation of these policy files as an additional
installation/configuration dependency, looks like we'll have to ratchet
that down to default to AES-128.  I'll go ahead and adjust that down,
and we can discuss and change back if necessary.

See more below:


Brent Putman wrote:
> Well, one immediate issue that I see is that in your metadata for your
> SP, in the SPSSODescriptor, there is no KeyDescriptor defined that
> specifies a key that can be used for encryption.  The only one there has
> "use='signing'".  You need to either add another KeyDescriptor with
> "use='encryption'", or if you want to use the same key for both, then
> omit the 'use' attribute entirely.  If this was generated by the
> TestShib metadata generator, then I suppose this needs to be addressed
> one way or the other. 
>   

This observation and advice are correct, but I think your logs don't jib
with the metadata you have shown there.  Methinks you must have slightly
different metadata for the SP that is getting used by the IdP, that does
have a key descriptor usable for encryption to the SP.  Your log clearly
shows an encryption key being resolved.  If it actually had
use="signing", that wouldn't be happening (I tested).  Can you confirm
that that is the case?  (just so I don't go crazy...).

FYI, if there is not a suitable encryption key resolved for the
recipient, then it does get correctly caught by the security utility
class as an invalid parameter, e.g see something like this:


08:01:31.399 ERROR
[edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler]
Unable to construct encrypter
org.opensaml.xml.security.SecurityException: Key encryption credential
may not be null
        at
org.opensaml.xml.security.SecurityHelper.buildKeyEncryptionParams(SecurityHelper.java:579)
        at
edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.getEncrypter(AbstractSAML2ProfileHandler.java:792)
        at
edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.buildResponse(AbstractSAML2ProfileHandler.java:227)





> Can you see what happens if you make this adjustment in your metadata? 
> We have successfully tested encrypted assertions, so I'm fairly certain
> that's the issue.
>   

So sounds like you already did that, just not in the copy you posted.



> However, it also uncovers another issue that the IdP isn't checking that
> an encryption key for the SP was resolved before it goes and tries to
> encrypt the assertions.   I'll look at fixing that tomorrow, unless Chad
> beats me to it.
>   

This is technically still true, but it does catch the exception that
gets thrown due to a null KEK credential parameter.  Question is:  what
should we do if the IdP config indicates to do encryption, but the
recipient doesn't have an encryption key published?    Should that be a
fatal error, or should the IdP just log it and proceed without doing the
encryption? The latter seems more correct to me, especially since we
typically will just have a single default security policy for all
relying parties.  I seem to remember us discussing that at some point.


> Also, the encrypter(s) are supposed to be doing some parameter sanity
> checking to ensure that a key encryption key is supplied before they
> attempt to do anything, and fail more gracefully if not.  I'm not
> immediately seeing why that it hasn't happening in this case.  I'll look
> into that also.
>   

False alarm, these checks do work correctly.  I was just confused about
whether a KEK had actually been resolved (it was).


--Brent