OpenSAML user discussion

[Brent Putman <>]

Ruthenbeck, Justin wrote:
>  
> Many thanks for the complete response.  Based on what you wrote, I've
> got my Attribute elements decrypting as I'd expect.
>   

Great.

>  
> 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.
>   

Well, note that you certainly could need to use other implementations of
those interfaces, rather than those specific ones.  That was just a
simple example to get you started, esp. given that (I was assuming) you
probably already had you private key for decryption handy, rather than
needing to resolve it in some more complex way.



>  
> Out of curiosity, it seems as though the SAML xml self describes the
> type of encryption being used. 

Yes, it does, if you're referring to the information in the
EncryptionMethod element inside the EncryptedData and EncryptedKey. 
That's just a standard part of the XML Encryption spec.

>  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?
>   
Well, having an EncryptedKey inside the KeyInfo is just one
possibility.  SAML actually defines another way: having the EncryptedKey
be a peer of the EncryptedData inside the EncryptedAttribute or
EncryptedAssertion.   You can also have other possibilities with
RetrievalMethod, and also other types of forward and/or back references
in the data and keys.  There's also other mechanisms used in
WS-Security.  And probably others, like using key management or key
escrow systems. And then there's the so-called "multicast" case for any
of the above, where there are actually multiple EncryptedKeys in the
same message, each encrypted with the public key of a different
recipient, and you have to figure out (resolve) which one is yours.

The xmltooling library doesn't make assumptions and tries to support
whatever is allowed and possible vis-a-vis the XML Encryption spec. 


All that said, it's likely that with standard SAML use cases, you'd just
supply a chaining one, with inline and SAML encrypted element type
members, and that would handle most common cases.  That is something for
the docs.

I suppose the SAML Decrypter subclass of the xmltooling Decrypter could
default something like that in with a different constructor variant.  I
might consider adding that.