OpenSAML user discussion

[Brent Putman <>]

Taylor, Christopher wrote:
> Hi,
>
>  
>
> decrypter.setRootInNewDocument(true) fixed it! Thanks Brent, Scott and 
> Joakim for the suggestions!
>   

Great, glad it worked.


>  
>
> I'm pretty new to OpenSAML (and SAML in general), but is verifying the 
> signature on a decrypted assertion (or XMLObject in general) really so 
> uncommon? 

No, it's probably common, Assertions are often signed.  But the other
things in SAML for example that can be encrypted (Attribute, NameID)
aren't signed.  And in general XML Encryption usage for other things, I
don't think it would generally be the case that it's necessarily
common.  It just depends on what you are doing, which is why it's an option.


> I'd actually run across the documentation Brent mentions below, but didn't 
> realize it applied to my use case. Maybe adding a constructor which allows 
> specifying this option (and adding the notice to its javadoc) would make it 
> more obvious.
>   

Well, maybe, but the class already has 3 args to its constructor.  Our
project style guidelines are that we generally keep it to 5 or under. 
My personal general rule is that if it's a fundamental requirement for
the class to function and no default is realistic, it's a constructor
arg.  If it's an optional param, or one that can have a default, then
it's a standard accessor/mutator pair.


I suppose we could also look at changing the default in the SAML
Assertion when decrypting Assertions  specifically, but that would make
the behavior asymmetrical.  Or we could add overloaded method variants
in the SAML class that take the param that override the default, like
the primary decrypt* methods in the superclass.