Grouper Users - Open Discussion List

[Darren Boss <>]

You can either terminate or pass through TLS using Nginx. I actually
do both as I have Nginx acting as a load balancer which is likely
irrelevant if you are just using Docker and not another container
orchestration environment. In that instance I use the stream module
and proxy protocol to pass on the traffic (works for any TCP or UDP
protocol, not just http). I use proxy protocol so later on I can still
have the client ip in http x headers.

My ingress controller (also Nginx) is the layer that terminates TLS
and routes traffic based on the url now with the client ip in
x-headers. At this point the traffic is now only routing in a private
network overlay so I'm far less concerned with unencrypted traffic
although I'm still cautious about what other services I run here. I
still have the option to pass through TLS at this layer as well if the
container is expecting TLS traffic so it's really up to the deployer
where you terminate TLS. If you can't trust the network, don't
terminate TLS.

On Tue, Jul 14, 2020 at 5:25 PM Baron Fujimoto <> wrote:
>
> Ahh, ok. To make sure I understand, the reverse proxy listens on the 
> standard port 443, and depending on the URI path routes the traffic to the 
> appropriate UI or WS docker container:
>
> RP: <https://grouper.example.edu/grouper>    (port 443) -> UI: 
> http(s?)://grouper.example.edu:8080/grouper>
> RP: <https://grouper.example.edu/grouper-ws> (port 443) -> WS: 
> http(s?)://grouper.example.edu:8888/grouper-ws>
>
> Currently, we terminate our TLS in the shared Tomcat servlet container. How 
> do you handle this when using the reverse proxy? Do you move the TLS 
> termination up to the RP and connect via http to the proxied docker 
> containers?
>
> On Mon, Jul 13, 2020 at 10:51:48PM -0400, Darren Boss wrote:
> >One option would be to set up a reverse proxy in front of the
> >containers that directs traffic to the correct container based on the
> >url pattern. That reverse proxy is grouper.example.edu and it has
> >rules so traffic to /grouper goes to the ui container while
> >/grouper-ws goes to the web services container. In Kubernetes, this is
> >a core part of the platform and called the ingress controller which is
> >typically done via Nginx.
> >
> >On Mon, Jul 13, 2020 at 8:15 PM Baron Fujimoto <> wrote:
> >>
> >> On Thu, Jul 02, 2020 at 05:15:31PM -1000, Baron Fujimoto wrote:
> >> >We're dipping our toes in the water of containerized Grouper, generally 
> >> >upgrading from 2.2 to 2.5. Upgrade issues aside, I have some basic 
> >> >questions about containerized Grouper that I hope aren't too stupid. I 
> >> >poked around the Grouper doucmentation I could find but didn't find 
> >> >what I was looking for – I'm happy to RTFM if someone will point me to 
> >> >TFM.
> >> >
> >>
> >> Different question:
> >>
> >> Our current grouper UI and WS deployments share a common hostname and 
> >> port (443).  E.g.:
> >>
> >> UI: <https://grouper.example.edu.grouper/grouper>
> >> WS: <https://grouper.example.edu.grouper/grouper-ws>
> >>
> >> We achieve this by running both services out of a shared Tomcat servlet 
> >> container. With dockerized Grouper the the best practice seems to be to 
> >> run each service in its own docker container (each with its own Tomcat 
> >> servlet container)?  Since each service can't listen to the same port 
> >> (right?), what is the recommended way of handling this? Just having, 
> >> say, the WS, listen to a different port? (Assuming we want to retain the 
> >> same hostname.) E.g.:
> >>
> >> UI: <https://grouper.example.edu.grouper/grouper>
> >> WS: <https://grouper.example.edu.grouper:9443/grouper>
> >>
> >> --
> >> UH Information Technology Services : Identity & Access Mgmt, Middleware
> >> minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
> >
> >
> >
> >--
> >Darren Boss
> >Senior Programmer/Analyst
> >Programmeur-analyste principal
> >
>
> --
> UH Information Technology Services : Identity & Access Mgmt, Middleware
> minutas cantorum, minutas balorum, minutas carboratum desendus pantorum



-- 
Darren Boss
Senior Programmer/Analyst
Programmeur-analyste principal