OpenSAML user discussion

[Brent Putman <>]

>         
>         Decrypter decrypter = new Decrypter(null, resolver, new 
> InlineEncryptedKeyResolver());
>         Assertion assertion = decrypter.decrypt(encryptedAssertion);
>         return new Saml2Formatter().marshall(assertion);
>     }
>
>
>   


I think that the problem is, you've got a mismatch between where your
SAML 2 Encrypter instance is placing the keys, and where you are telling
the Decrypter above to resolve them.  The Encrypter by default places
them as direct children of the SAML EncryptedElementType (e.g.
EncryptedAssertion), in other words, as peers of the EncryptedData.  In
the Encrypter Javadocs that's what is called PEER placment.  I did
notice that that default was mis-documented in the Javadoc for the
Encrypter.  I fixed it in Subversion.  For the record, it should say
that the default for the keyPlacement property of the Encrypter is
Encrypter.KeyPlacement.PEER, not INLINE.  Maybe that was what was
throwing you off.

The InlineEncryptedKeyResolver you're using, on the other hand, only
resolves EncryptedKey's that are children of the EncryptedData's KeyInfo
(that's what's meant by INLINE). 


>
> I did step through the code a little, and it appears that part of the 
> problem is that the InlineEncryptedKeyResolver is unable to get the list of 
> encrypted keys from the encrypted data.


Right, because they aren't there.  :-)    For the default Encrypter key
placment of PEER, use the SAML 2
EncryptedElementTypeEncryptedKeyResolver, which knows how to handle the
EncryptedData that is part of a SAML 2 EncryptedElementType (although
see end of this message for better solution).




>  In this case, there aren't any ds:EncryptedKey child elements because the 
> ds:KeyInfo element only contains a ds:RetrievalMethod child element.
>   


Yeah, it contains a RetrievalMethod b/c that's what the SAML E43 errata
says to do in the case of placing the keys as peers of the
EncryptedData.    BTW, I believe use of a
SimpleRetrievalMethodEncryptedKeyResolver (rather than
EncryptedElementTypeEncryptedKeyResolver) in the Decrypter would also
resolve those correctly.


> Am I doing something wrong or is the decryption of assertions in this 
> format not supported yet?  If it isn't supported yet, is there an easy way 
> to get OpenSAML to put the keys directly in the ds:KeyInfo element of the 
> encrypted data?  I'm using OpenSAML 2.3.1.
>   


No, it's all supported.


If you want or need the EncryptedKey's "inline" within in the
EncryptedData's KeyInfo, just call encrypter.setKeyPlacement(INLINE)
before you do the encryption.  Then they should be resolvable by the
InlineEncryptedKeyResolver.

Another suggestion is:  In the real world, for an actual deployment, you
don't necessarily know in advance how someone sending you encrypted SAML
structures will place the EncryptedKeys.  So the best thing to do is
actually supply the Decrypter with a ChainingEncryptedKeyResolver, that
as members has any or all of the above.  That way you cover all the
bases.  They will be evaluated in the order they are added to the
chaining resolver's List.

HTH,
Brent