<div dir="ltr"><div><span class="gmail-im"><div></div></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Generating a new SAML key
every day would not be seen as a best practice. Doing that would require
you to perform a key roll-over every day, which requires getting the
new metadata to every IdP using the SP every day. Not good.</div><div><br></div><div>The
usual approach would be to keep one, long-lived key, but acquire it
from a secrets store at runtime rather than building it in statically.</div></blockquote></div><div><br></div><div>Thank you -- this is what I was looking for. The rest is as you surmised -- installation is happening in the Dockerfile, the image that's built from that is what gets run. We'll be using AWS Secrets Manager to pass things in -- but in testing now, the main point was to re-use one cert and key, rather than new ones for every build of the image.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 3:48 PM Ian Young <<a href="mailto:ian@iay.org.uk">ian@iay.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><blockquote type="cite"><div>On 2020-05-05, at 16:05, David Wen Riccardi-Zhu <<a href="mailto:davidwen.riccardizhu@gooduncle.com" target="_blank">davidwen.riccardizhu@gooduncle.com</a>> wrote:</div><br><div><div dir="ltr"><div>My
Dockerfile installs Apache and Shibboleth, copies over the SAML
certificate and key into the container, and finally starts the
Shibboleth daemon and httpd service.</div></div></div></blockquote><div><br></div><div>I'm not clear exactly what you're doing here. Dockerfiles are normally used to generate images which are then stored in a repository, rather than being used as the way to deploy a service directly. There's a grey area, though, because doing a `docker build` does cause the Dockerfile to run the commands in a container. I guess you _can_ use that as a deployment technique, but it's very unusual. </div><div><br></div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div>I do this to make sure that the
autogenerated keys on installation don't replace the ones currently in
use, if the container gets restarted.</div></div></div></blockquote><div><br></div><div><div>This sounds as if you're installing Apache and Shibboleth on container startup: again, the normal process is to do that installation as part of the creation of the image, not on container startup. My apologies if I've misunderstood what you're saying here.</div><div><br></div><div><br></div></div><blockquote type="cite"><div><div dir="ltr"><div>I'm
wondering if I'm missing anything with this approach.</div></div></div></blockquote><div><br></div><div>Clarifying the above might help us understand this better.</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div> I've come across
some documentation discussing rollovers, as well as generating a new
certificate and key daily. Is that seen as a best practice, or am will
my approach work?</div></div></div></blockquote><div><br></div><div>Generating a new SAML key every day would not be seen as a best practice. Doing that would require you to perform a key roll-over every day, which requires getting the new metadata to every IdP using the SP every day. Not good.</div><div><br></div><div>The usual approach would be to keep one, long-lived key, but acquire it from a secrets store at runtime rather than building it in statically.</div><div><br></div></div>Hope that helps,<br><div>
<span style="border-collapse:separate;font-variant-ligatures:normal;font-variant-east-asian:normal;line-height:normal;border-spacing:0px"><div style="overflow-wrap: break-word;"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div><span style="white-space:pre-wrap"><br></span> -- Ian<br></div><div><span style="font-size:medium"><br></span></div></span></div></span><br><br>
</div>
<br></div>-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a></blockquote></div>