Grouper Users - Open Discussion List

[Baron Fujimoto <>]

Interesting. Again, to make sure I understand this scenario, you describe 
having the LB terminate the TLS using a standard CA issued certificate. From 
there, you forward the traffic – also via TLS to the back end containerized 
service which is using its own, potentially long-lived (say, to alleviate 
renewal and cert management issues?), self-signed cert? I suppose this would 
depend on the capabilities of the LB as well to support this.

I concur it would be preferable to encrypt all the network channels where 
feasible.

On Thu, Jul 16, 2020 at 12:10:55PM +0000, Black, Carey M. wrote:
> I think it is also reasonable to point out:
>
> Even if you terminate TLS at a Load balancer, you can still use SSL past that 
> point too.
>         Yes, any break in the TLS is a "point of concern". However, IMHO, anywhere you 
> are using http is also an "area of concern" too.
>         AKA: If you are accepting of the "network risk" and use http, then 
> that is a choice. But there are other choices too. 😊
>         A lot of load balancer's are very accepting of self signed certs on the back 
> end web servers. And that at least reduces the "network snooping" risks.
>
> And really, if your Load balancer is compromised then what is really "safe" 
> at that point? ( So don't let that happen. 😊 )
>
> --
> Carey Matthew 
>
> -----Original Message-----
> From:  
> <> On Behalf Of Coleman, Erik C
> Sent: Thursday, July 16, 2020 12:32 AM
> To: Baron Fujimoto <>; Grouper Users 
> <>
> Subject: RE: [grouper-users] containerized grouper noob questions
>
> Baron,
>
> We do exactly the last part-- our TLS is terminated at the AWS App Load 
> Balancer, and then everything is proxied non-SSL behind the ALB to the 
> containers, with separate UI and ws container.  We're still on 2.4.0 so 
> Apache is in the middle of that using AJP to Tomcat.  So ours looks something 
> like:
>
> RP: 
> <https://urldefense.com/v3/__https://grouperapp.someschool.edu/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxGql1Rtw$
>  > (port 443 on ALB) --> UI: 
> https://urldefense.com/v3/__http://ui-container-host:80__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxF_MP6Eg$
>   (Apache) -> 
> https://urldefense.com/v3/__http://localhost:8009__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9Nx7MwdG-0$
>   (AJP)
>
> I think this is simplified in 2.5.x.
>
> -Erik Coleman
>
>
> -----Original Message-----
> From:  
> <> On Behalf Of Baron Fujimoto
> Sent: Tuesday, July 14, 2020 4:25 PM
> To: Grouper Users <>
> Subject: Re: [grouper-users] containerized grouper noob questions
>
> 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://urldefense.com/v3/__https://grouper.example.edu/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9Nxz2MxruA$
>  >    (port 443) -> UI: http(s?)://grouper.example.edu:8080/grouper>
> RP: 
> <https://urldefense.com/v3/__https://grouper.example.edu/grouper-ws__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxYt8uxJo$
>  > (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://urldefense.com/v3/__https://grouper.example.edu.grouper/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxbmCVFhw$
> > >  >
> > > WS: 
> > > <https://urldefense.com/v3/__https://grouper.example.edu.grouper/grouper-ws__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxC30Ad0M$
> > >  >
> > >
> > > 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://urldefense.com/v3/__https://grouper.example.edu.grouper/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxbmCVFhw$
> > >  >
> > > WS: 
> > > <https://urldefense.com/v3/__https://grouper.example.edu.grouper:9443/grouper__;!!KGKeukY!luKFNsk2bJ4Ek1qq6WR4fAhaX6JyqYxeeXMQ9tJvoJlx4YqgWjsMsA5mU9NxuvRjJAU$
> > >  >
> > --
> > Darren Boss
> > Senior Programmer/Analyst
> > Programmeur-analyste principal

--
UH Information Technology Services : Identity & Access Mgmt, Middleware
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum