OpenSAML user discussion

["Ruthenbeck, Justin" <>]

Brent,
 
Many thanks for the complete response.  Based on what you wrote, I've
got my Attribute elements decrypting as I'd expect.
 
I think my confusion (and this is coming from someone new to SAML) came
with how to construct the Decrypter.  It was unclear that I needed an
InlineEncryptedKeyResolver() and a StaticKeyInfoCredentialResolver() as
the specific arguments.  Given your sample, it's now makes sense why
those are used and what they do.
 
Out of curiosity, it seems as though the SAML xml self describes the
type of encryption being used.  In my case (symmetric key encrypted with
provided public key), each <saml:EncryptedAttribute> defines the
<xenc:EncryptedKey> along with the CipherValue.  Why do I need to
explicitly specify an InlineEncryptedKeyResolver then?  Why can't the
framework figure out from the SAML itself that there's an inline key to
use?

Thanks again for the help - much appreciated!
justin

PS: Anything you can add to OSTwoUserManJavaXMLEncryption (even if just
the contents of your original response) would be hugely appreciated by
anyone in a situation similar to my own.



________________________________

        From: Brent Putman 
[mailto:]
 
        Sent: Thursday, February 05, 2009 6:13 PM
        To: 

        Subject: Re: [OpenSAML] Decrypting SAML from File
        
        


        Ruthenbeck, Justin wrote: 

                
                Question: Is there a high level API to which I can give
my private key and let it handle the XML decryption for me?


        Yes.
        
        

                 
                I've looked at the Decrypter object but quickly realized
that it requires familiarity with quite a few decryption related
classes.  I would expect that there's a higher level class that takes
encrypted SAML (via an XMLObject) in and outputs a decrypted version -
no special knowledge required of
symmetric/assymetric/inline/reference/AES/RSA usage.



        Well, the OpenSAML Decrypter in the
org.opensaml.saml2.encryption package *is* the high-level API.  It
doesn't really get much higher than that.  It's literally:
        
        Foo foo = decrypter.decrypt(encryptedFoo)
        
        It does inherit from the XML Decrypter, which does have a lot of
lower-level methods for dealing with things manually and for special
cases, but for SAML you can mostly ignore those.
        
        
        The complexity comes in when you consider how you might go about
resolving the right decryption key to use.  You do need to know 1) that
you're using asymmetric crypto for EncryptedKey transport (vs. possibly
a pre-shared symmetric key for data encryption or something), and 2) if
the former is the case, also how the sender is going to send you the
encrypted data encryption key.  There's really no way to avoid dealing
with those questions, and is largely determined by the whoever is
sending you the encrypted data.  They need to inform you as to what they
are going to do.
        
        FYI, probably the most common case is an EncryptedKey carrying
the symmetric data encryption key which has been encrypted with RSA.
        
        If you're doing asymmetric crypto (since you mentioned private
key),  and they are sending you an EncryptedKey located inside the
EncryptedData/KeyInfo, then something as simple as this will suffice:
        
                
                Credential decryptionCredential =
SecurityHelper.getSimpleCredential(publicKey, privateKey); 
                StaticKeyInfoCredentialResolver skicr = new
StaticKeyInfoCredentialResolver(decryptionCredential);
                
                Decrypter decrypter = new Decrypter(null, skicr, new
InlineEncryptedKeyResolver());
                
                try {
                    Attribute decryptedAttribute =
decrypter.decrypt(encryptedAttribute);
                } catch (DecryptionException e) {
                    e.printStackTrace();
                }
        
        
        You could also instead use a Credential Resolver to resolve your
decryption key in some more complex manner, esp. if you will have more
than one.
        
        If they're sending you the EncryptedKey as a child of the SAML
encrypted type, rather than in the EncryptedData/KeyInfo, then you would
use the EncryptedElementTypeEncryptedKeyResolver rather than the Inline
one.  Even better, combine them both with a
ChainingEncryptedKeyResolver, and then it will work for both cases, and
you won't have to care.
        
        
        
        

                
                
                 
                Unfortunately, the page that would hold this info
(https://spaces.internet2.edu/display/OpenSAML/OSTwoUserManJavaXMLEncryp
tion) seems to be blank.  :(


        Yes, sorry about that.  I've been meaning to work on that for
ages.   I'll add some docs and examples there tomorrow.  However, the
docs for the 2 Decrypter classes do explain most of this, at least the
arguments for the constructor, which is mostly what you need to know:
        
        
        
http://www.opensaml.org/docs/opensaml/2.2.2/apidocs/org/opensaml/saml2/e
ncryption/Decrypter.html
        
        
http://www.opensaml.org/docs/opensaml/2.2.2/apidocs/org/opensaml/xml/enc
ryption/Decrypter.html
        
        
        
        HTH,
        Brent