Solved

OAuth login connector - oauthredirecturi Extended property not working?

  • 24 February 2023
  • 17 replies
  • 217 views
A
Rank
Userlevel 5
Badge +8

I'm trying to test the recently released OAuth login connector support in the Universal GUI. Thanks to the Docs I conclude that I have to update the Extended property oauthredirecturi to switch from http to https.

  • I did this on our TEST environment for the Application in which I am testing this
  • We had the Indicium recycled after the change
IAM Extended property
Azure AD error

@Vincent Doppenberg However, the error still mentions the http uri. Could it be that the Universal GUI does not look at the IAM Extended property override?

Another question: previously we always used the /signin-microsoft for this scenario in Insomnia. Why is this changed to oauth-callback and should we register both Reply URLs in the Azure AD App or update to oauth-callback for the OpenID Provider scenario too?

icon

Best answer by Vincent Doppenberg 24 February 2023, 12:25

View original
This topic has been closed for comments

17 replies

V
Rank
Userlevel 6
Badge +4

Hello Arie,

I have asked if someone from the Universal GUI team can answer your first question. As for your second question, we couldn’t use the /signin-X URL for the process action due to a technical reason. So there are indeed two return URLs which should be registered.

A
Rank
Userlevel 5
Badge +8

@Vincent Doppenberg Thanks, will await further clarification from Universal team

Leroy Witteveen
Rank
Userlevel 2
Badge +2

Hello @Arie V,

Universal unfortunately doesn't have support for the OAuthRedirectURI extended property yet, so this probably explains the problem you're facing.

Kind regards,
Leroy Witteveen

V
Rank
Userlevel 6
Badge +4

Hello Arie,

On second thought, you shouldn’t need this extended property for the Universal GUI with Indicium. The return URL will be based on the request URL that arrives at Indicium. The fact that it turns into http:// indicates that there is a reverse proxy which handles https:// and communicates to Indicium over http://.

The issue here is mostly likely caused by the lack of a proper Reverse Proxy configuration for Indicium, as documented here.

I hope this helps.

A
Rank
Userlevel 5
Badge +8

Hello Arie,

On second thought, you shouldn’t need this extended property for the Universal GUI with Indicium. The return URL will be based on the request URL that arrives at Indicium. The fact that it turns into http:// indicates that there is a reverse proxy which handles https:// and communicates to Indicium over http://.

The issue here is mostly likely caused by the lack of a proper Reverse Proxy configuration for Indicium, as documented here.

I hope this helps.

@Vincent Doppenberg Unfortunately it's a bit more complicated than that.

Our appsettings.json is configured as instructed in the Docs:

"ReverseProxy": {
        "Enabled": true,
        "AllowedHeaders": [
            "XForwardedProto"
        ],
        "CustomHeaders": {
            "XForwardedProto": "X-FORWARDED-PROTO"
        }

However, we use an AWS Application Load Balancer in front of our Elastic Beanstalk EC2 servers. And the communication between the ALB and the EC2 is HTTP at the moment, not HTTPS. So, I suppose that explains why HTTP is returned. It is still on our backlog to evaluate and decide whether to bring this to HTTPS too.

@Leroy Witteveen should I raise a TCP to request this support from the Universal GUI? Currently, without that setting I basically cannot use the OAuth login connector.

V
Rank
Userlevel 6
Badge +4

Hello Arie,

While this would fix your problem, it should not be necessary for the ALB to communicate over https with the EC2 server. This is exactly what the purpose of the X-Forwarded-Proto header is. The ALB should send an X-Forwarded-Proto header to Indicium on the EC2 server to tell Indicium: “Even though this request was done via http, my external address is actually https”. This knowledge allows Indicium to use https for all of the URLs it generates and communicates back to the Universal GUI.

With that said, I’m not sure why your configuration isn’t working, because the ALB should be sending the X-Forwarded-Proto header. I think you can remove the CustomHeaders section from the appsettings, but I’m not certain that this will fix the problem.

As for the extended property, there is no need for the Universal GUI to implement this. Indicium determines the return URL that is used and it does so based on the requests it received. This issue should be completely solved if we can get the ALB and EC2 to communicate properly.

Can you try it out without the CustomHeaders section?

V
Rank
Userlevel 6
Badge +4

Hello Arie,

To follow up on my previous answer, I think the problem could be caused by not having specified KnownNetworks in Indicium’s reverse proxy settings. I’ve seen this happen before with Azure Front Door for instance.

You will have to find the IP range of the ALB which is sending the traffic to Indicium. This link might help. And then configure it similar to how it is described here.

If this solves your problem, please let us know so we can update our AWS documentation accordingly.

A
Rank
Userlevel 5
Badge +8

@Vincent Doppenberg Just tried with the CustomHeaders section removed from the appsettings.json and that does indeed make no difference.

Configuring KnownNetworks / fixed IP-addresses is explicitly something we don't want for services in a Cloud environment. As also warned for by AWS in the link you provided:

Important: The IP addresses for Classic Load Balancers and Application Load Balancers change over time. Avoid using this information to statically configure your applications to point to these IP addresses.

The alternatives I can think of so far:

  • Extended property support by Universal GUI → seems relatively easy to add
  • Force HTTPS between ALB and EC2 → new for us, unclear of the impact yet

Any other ideas for a simpler/better alternative?

V
Rank
Userlevel 6
Badge +4

Hello Arie,

Regarding this:

Configuring KnownNetworks / fixed IP-addresses is explicitly something we don't want for services in a Cloud environment. As also warned for by AWS in the link you provided:

Important: The IP addresses for Classic Load Balancers and Application Load Balancers change over time. Avoid using this information to statically configure your applications to point to these IP addresses.

The KnownNetworks configuration allows you to specify a so called CIDR block which covers an entire subnet. Usually when an IP address is dynamic, it remains within the same subnet, this is the case for proxies on Azure for instance. So for example, the CIDR block 10.10.0.0/16 covers the entire 10.10.x.y set of IP addresses. However I'm not certain that AWS's dynamic IP addresses also stay within the same subnet, it's difficult to find good documentation on this.

Could you try to set up the KnownNetworks with the current IP space of your ALB just to confirm that this would work as a solution? If this solution works and we can find all possible IP spaces for the ALB, then this solution is highly preferable over both of your suggestions.

 

A
Rank
Userlevel 5
Badge +8

Hi @Vincent Doppenberg The same goes more or less for AWS VPC's, so we configured the KnownNetworks as follows in the appsettings.json, but I'm still getting the redirect to HTTP. Could you verify if our configuration is correct?

 

V
Rank
Userlevel 6
Badge +4

Hello Arie,

Your configuration looks correct, but I can't vouch for the IP spaces that you configured. Since it’s not working, my main guess would be that they're not correct or that you didn't restart Indicium.

Where you did you find these IP spaces?

R
Rank
Badge

Hi @Vincent Doppenberg 

@Arie V asked me to doublecheck the CIDR blocks as configured in the KnownNetworks list. I can confirm that they are the correct ones. Each CIDR block corresponds to the IPv4 CIDR block belonging to a subnet in which the load balancer is configured (two subnets in total)

A
Rank
Userlevel 5
Badge +8

@Vincent Doppenberg Since the KnownNetworks solution is not working for us, I have Declined the solution for TCP 2773 in which the Universal team claimed to have provided support for the OAuth login connector. I hope you guys will be able to pick this up and tell us how to get the OAuth login connector working as expected on AWS with an ALB. 

V
Rank
Userlevel 6
Badge +4

Hello Arie,

We can offer the extended property as a temporary solution, however, I would like to send you a version of Indicium with some additional logging as well, to get the reverse proxy configuration to work. Once this works as intended, the extended properly will no longer be necessary.

I'll send both versions to you tomorrow.

A
Rank
Userlevel 5
Badge +8

Hi @Vincent Doppenberg 

There is not really an urgency for us to get this working, so I'm fine with the both of us working towards the final solution and not waste energy on a temporary solution.

V
Rank
Userlevel 6
Badge +4

Oh that's good to know, I thought this might have been urgent for that release that was mentioned. In that case I will only send the version with extra logging so we can sort out the reverse proxy settings. I'm pretty confident that we can get this to work, but it's difficult to determine the issue from the outside. It's probably a good idea for us to make this logging permanent for that very reason.

A
Rank
Userlevel 5
Badge +8

@Vincent Doppenberg Not everything is urgent for us, luckily 😀 The additional login options were, we intend to go live with that upcoming Wednesday indeed. 

Terms & ConditionsCookie settings