DataSealer dependencies

[Cantor, Scott]

> I wasn't planning on using client-side storage, so I didn't think I needed the
> DataSealer keys and commented them out of the configuration and the
> properties file. After that, the idp failed to initialize and I determined that
> there were a number of configuration files that reference the DataSealer
> implementation. Is it a hard dependency to have the DataSealer
> key/password configured and the files present even if you are not using
> client-side storage? Is it used for anything else; in particular, if you are not
> using the client-side storage implementation, is it still a security requirement
> to regularly rotate the DataSealer key?

A lot of the early-defined properties and components were hardwired into Spring before I had a better handle on things, and I think in this particular case the trick is marking them lazy-init. But there are a lot of beans that use it, some of which are probably hard to avoid the initialization of even if they don't end up getting used.

Based on a search, the list of use cases is:

- client-side storage (*)
- crypto strategy for transient IDs (*)
- serialization of passwords saved into authentication results
- a logout dependency that I think is baked in but not actually being used (think this is just a bug)

(*) used by default

I would suggest filing a bug and we can maybe figure out how to get everything to start up safely if none of the features are being used.

The one that may be trouble is the third one, because that's sitting in a list of principal serializers and I'm not sure if it can be made optional, will have to play with it.

-- Scott