Dockerized IdP

[John Gasper]

Etienne,



With our cloud service we plan to eventually want to run hundreds of
configs. For the time being each client will have their own VMs, but we
are hosting with AWS and ECS support of Docker is first rate. Meaning we
do not have a lot of system config changes to manage.

With that said, if one is only looking at Docker for the IdP then Docker
is probably over kill... But containerization will take over just like
virtualization took over. When it does, containerizing the IdP makes lots
of sense.

Ian,

Item A, I'll check to see if the license is include in the otherwise
unmodified Java distribution.
Item B, I'll check with Unicon's executives to see what they think about
the indemnification section. If not, then yes I suppose we'll need to
figure something else out, either using and throughly testing OpenJDK
releases (which is much easier to do in container since the releases are
controlled) or just providing the tidbits to add to the user's own image,
which I think I mentioned in an earlier email.

Perhaps it does not matter, but I do not actually push to Docker Hub, but
it does an automated build. :D

>
>------------------------------
>
>Message: 3
>Date: Tue, 8 Mar 2016 11:03:27 +0100
>From: Etienne Dysli-Metref <etienne.dysli-metref at switch.ch>
>To: users at shibboleth.net
>Subject: Re: Dockerized IdP
>Message-ID: <56DEA36F.4000009 at switch.ch>
>Content-Type: text/plain; charset="utf-8"
>
>On 07/03/16 22:40, John Gasper wrote:
>> I wanted to take a moment and share a project that I've been working on
>> for the last year. That project is a dockerized Shibboleth IdP image,
>> which includes Java and Jetty. With this image, one simply overlays
>> their local configuration changes, builds the custom image, and they are
>> up in seconds. If someone needs a new configuration, it supports easily
>> provisioning (and externalizing) a new IdP configuration.
>
>Thanks for sharing John!
>One question that always puzzled me with Docker is: how do you properly
>manage the application's configuration? Your example shows several
>possibles answers. :)
>
>I think externalising the whole configuration is best, because then you
>would only have one image to build and you could run it several times
>with different configurations. (Assuming a context where one would run
>many IdPs, one per customer.)
>
>How many IdP (same or different config) do you plan to run with Docker?
>on how many hosts?
>
>> I think this is the answer if you are thinking of running the IdP in
>> Docker, but feel free to make up your own mind.
>
>What does thing bring compared to managing IdPs with configuration
>management software? I mean you'd need CM anyway to create the IdP's
>configuration (whether in the image or external), so why bother with
>Docker on top of this?
>
>Cheers,
>   Etienne
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 836 bytes
>Desc: OpenPGP digital signature
>URL: 
><http://shibboleth.net/pipermail/users/attachments/20160308/249570c1/attac
>hment-0001.sig>
>
>------------------------------
>
>Message: 4
>Date: Tue, 8 Mar 2016 11:27:51 +0000
>From: Ian Young <ian at iay.org.uk>
>To: Shib Users <users at shibboleth.net>
>Subject: Re: Dockerized IdP
>Message-ID: <BDA9EA80-D901-4848-A278-C1A1A2FDD72F at iay.org.uk>
>Content-Type: text/plain; charset="us-ascii"
>
>
>> 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
>