[mitreid-connect] Redirected back to main page??

Wed Nov 25 13:11:19 EST 2015

Sessions and other pieces of system management are tied to the hostname of the incoming request. The issuer value will force everything to go to whatever URL is in that field in future requests. So basically, you start on host “A” and end up on host “B”, and even though they’re the same machine they act differently, like you just showed up. So you start the process on “A” and it says you need to log in. So it remembers what you’re trying to access and sends you to the login form.  However, the issuer is set to “B” and so the login page redirect is on “B”. That means the login form is submitted on “B”, and the session on “A” is never found. That means that the remembered page at the beginning is forgotten.

The only way this server is designed to work is for the “issuer” field in the configuration bean to be set to the public URL of the server, regardless of any intermediary systems. Any other setup whatsoever will break in one form or another. You’re lucky in that it’s breaking on the login form and not in some more subtle way further down the line (which I’ve seen happen).

So just set the issuer field to the final, external, public URL and call it a day. That should work through any number of intermediaries so long as you’re always accessing the system through that final, external, public URL and not anything else.

Hope this helps,
 — Justin

> On Nov 25, 2015, at 9:17 AM, Luiz Omori <luiz.omori at duke.edu> wrote:
> 
> Sorry Justin, still having problems connecting both. From the OAuth negotiation point of view (Authorization Code flow), which exact step is affected by a discrepancy in those two fields?
> 
> The failure we are observing happens at the point where the server tries to display the approval form, the login works fine. Even in that case the issuer configured in MitreId is correct in the sense that there is a valid listener there. Our simplified test environment consists of a single Tomcat and client running on the same machine, no load balancer or Apache.  In particular, why 127.0.0.1 is different than localhost for the authorization code flow? We can successfully login directly to MitreId using either.
> 
> I do understand that if the client tries to use the issuer field from the JWT token provided by MitreId, that may cause some problems but that is something else. The failure we are observing is before that.
> 
> Regards,
> Luiz
> 
> From: Justin Richer
> Date: Tuesday, November 24, 2015 at 6:37 PM
> To: Luiz Omori
> Cc: "mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>"
> Subject: Re: [mitreid-connect] Redirected back to main page??
> 
> Yes, this is by design. Your issuer URL needs to be the same URL used to make the requests, regardless of the machine that the server is running on. Otherwise nothing will work! For example, many instances I’ve run have Tomcat running on localhost:8080 and not listening to the outside world, but fronted by apache. The issuer URL is whatever URL the apache server is fronting, not what Tomcat uses internally.
> 
>  — Justin
> 
>> On Nov 24, 2015, at 5:31 PM, Luiz Omori <luiz.omori at duke.edu <mailto:luiz.omori at duke.edu>> wrote:
>> 
>> Oh, I could reproduce the exact same behaviour by just having the issuer property defined in the server-config.xml different than the root url used to make the requests. For example, my server-config.xml has issuer "http://127.0.0.1:8080/ldap-openid-connect-server <http://127.0.0.1:8080/ldap-openid-connect-server>/“ and my test client is calling http://localhost:8080/ldap-openid-connect-server/authorize <http://localhost:8080/ldap-openid-connect-server/authorize>. Since I’m running everything on my laptop they are semantically identical. If both are either 127.0.0.1 or localhost it works. Is this by design? 
>> 
>> Regards,
>> Luiz
>> 
>> From: Justin Richer
>> Date: Tuesday, November 24, 2015 at 2:54 PM
>> To: Luiz Omori
>> Cc: "mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>"
>> Subject: Re: [mitreid-connect] Redirected back to main page??
>> 
>> I’m talking about something related to tomcat itself:
>> 
>> https://www.mulesoft.com/tcat/tomcat-clustering <https://www.mulesoft.com/tcat/tomcat-clustering>
>> 
>> If there’s only one instance of the server though then it should work fine so long as the load balancer is passing all headers (like cookies) through to the other side. Most common deployments of this software in enterprise space use a reverse proxy of some type, so a single-instance load balancer shouldn’t be different from that.
>> 
>>  — Justin
>> 
>>> On Nov 24, 2015, at 2:21 PM, Luiz Omori <luiz.omori at duke.edu <mailto:luiz.omori at duke.edu>> wrote:
>>> 
>>> Are you talking about MitreId own DB (in-memory versus MySQL versus …) or something else purely related to Tomcat?
>>> 
>>> In any case for now we have only one MitreId instance behind the load balancer as the second instance is not ready yet.
>>> 
>>> Regards,
>>> Luiz
>>> 
>>> From: Justin Richer
>>> Date: Tuesday, November 24, 2015 at 2:18 PM
>>> To: Luiz Omori
>>> Cc: "mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>"
>>> Subject: Re: [mitreid-connect] Redirected back to main page??
>>> 
>>> Do you have Tomcat’s shared session mechanism set up on your servers? You have to do that with a load-balanced setup otherwise things that are stored in the session object (like the target page after a login) will get lost.
>>> 
>>>  — Justin
>>> 
>>> 
>>>> On Nov 24, 2015, at 2:16 PM, Luiz Omori <luiz.omori at duke.edu <mailto:luiz.omori at duke.edu>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> We are having a problem with MitreId Connect when it’s behind a load balancer. Everything works as expected when we hit it directly but when we use the load balancer address the server does the authentication however instead of redirecting the authorization code back to the client it appears to send it to MitreId main page, with the user logged in to it. In the latter case, we even don’t see the approval form. 
>>>> 
>>>> Regards,
>>>> Luiz
>>>> _______________________________________________
>>>> mitreid-connect mailing list
>>>> mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>
>>>> http://mailman.mit.edu/mailman/listinfo/mitreid-connect <http://mailman.mit.edu/mailman/listinfo/mitreid-connect>
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20151125/757cfc5b/attachment.html