DataSealer dependencies

Kirill ks.grishin at gmail.com
Mon Mar 7 20:12:10 EST 2016


> if you are not
> using the client-side storage implementation, is it still a security
requirement
> to regularly rotate the DataSealer key?

It is funny how I was going to ask the same question.

So, Scott, if I have session disabled, I understand that I should not worry
about the keys rotation. Is my understanding correct?

Thanks,
Kirill

On Tue, Mar 8, 2016 at 5:27 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > 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
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160308/5078ec7f/attachment.html>


More information about the users mailing list