Dockerized IdP

[Ian Young]

> On 7 Mar 2016, at 23:02, Tom Scavo <trscavo at gmail.com> wrote:
> 
> On Mon, Mar 7, 2016 at 5:53 PM, John Gasper <jgasper at unicon.net> wrote:
>> 
>> Thoughts?
> 
> I'll defer to Ian on this one. Last summer he recommended that the
> mdq-server [1] project switch to OpenJDK and we agreed with him. Each
> project has its own requirements, however, so I'll speculate further.

mdq-server seems to work just fine with OpenJDK, in particular with no weird memory leaks over multiple months of continuous runtime. OpenJDK seems to work for most applications.

However, we have historically seen problems with OpenJDK and the Shibboleth IdP, which is why the Shibboleth project recommends Oracle's JDK for production deployments of that product. That's also why my own probably less sophisticated Dockerized IdP (https://github.com/iay/shibboleth-idp-docker) uses an Oracle JDK-based base image. However, as I describe in the README there, Oracle's license terms essentially do not allow *anyone* to distribute the Oracle JDK as part of a Docker image. That's why there isn't a standard Docker library image for Oracle-based Java any more, despite how useful that would be. (There used to be one as part of the old dockerfile/java, but it was suppressed for this very reason when they moved to the new official builds system.)


> On 7 Mar 2016, at 22:53, John Gasper <jgasper at unicon.net> wrote:
> 
> Thanks Greg.
> 
> Tom,
> 
> Let me start by saying I am not a lawyer and do not pretend to be one, but
> I think it falls within the terms of:

[...]

> (v) you only distribute the Software
> subject to a license agreement that: (a) is a complete, unmodified
> reproduction of this Agreement; or (b) protects Oracle's interests
> consistent with the terms contained in this Agreement and that includes
> the notice set forth in Section H, and (vi) you agree to defend and
> indemnify Oracle and its licensors from and against any damages, costs,
> liabilities, settlement amounts and/or expenses (including attorneys'
> fees) incurred in connection with any claim, lawsuit or action by any
> third party that arises or results from the use or distribution of any and
> all Programs and/or Software.

Are you doing that? I really doubt that you're doing either (a) or (b), and I would be astonished if you (either personally or through your employer) are prepared to stand up for (vi).

If you're pushing a Docker image to Docker Hub, the person pulling that image gets no opportunity to sign up for Oracle's license.

> If there is a consensus that the image should not include Java, it can
> certainly be removed and left as an exercise of the user, much like I do
> with the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction
> Policy Files (See https://hub.docker.com/r/unicon/shibboleth-idp/.) Or,
> someone can mount a JRE/JDK directory on the Docker host. Personally, I'm
> not a fan of OpenJDK as I've seen it break too many clients IdPs when they
> ran an OS update and the IdP quit starting-up.

Although it is hugely annoying, and has been hugely annoying for the Java-on-Docker community for a long time, the only way I've seen to get round the legal issues here (other than just ignoring them and hoping for the best) is to defer it to the consumer. You do that by publishing something like https://github.com/iay/java-docker and telling people to do their own docker build of that, and then basing your own docker build on top. That doesn't give users the convenience of just using "docker pull" from the hub to get an IdP, but it means they have to go through accepting Oracle's license as part of the build and you never make a public image containing the Oracle JDK.

One option would be to base the thing you push to Docker Hub on an OpenJDK base image, but provide instructions for changing that to manually build an Oracle-based image, perhaps providing additional Dockerfiles.

    -- Ian




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3563 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20160308/7e1ad600/attachment-0001.p7s>