Here is my environment:
Multitenant with subdomain (e.g. t01.app.com) as the tenant identification strategy.
Using IdentityServer4 for issuing token. Each tenant will have his own issuer. E.g. t01.app.com is the issuer for t01.
Using Ocelot as the gateway
I am hoping to achieve such that the Ocelot is able to redirect with subdomain as a wildcard
Browser A invokes t01.ocelot.com -> Ocelot redirects to t01.app.com
Browser B invokes t02.ocelot.com -> Ocelot redirects to t02.app.com
Anyone can help me out? Or suggest some other gateway which can support this.
Related
As part of our Azure AD and HashiCorp Vault OIDC single sign-on implementation, I have registered an application in our corporate Azure AD and provided a couple of allowed redirect URIs in my Terraform configuration that are along the lines of the following:
allowed_redirect_uris="http://localhost:8250/oidc/callback"
allowed_redirect_uris="https://{hostname.domain}:8200/ui/vault/auth/oidc/oidc/callback"
The terraform configuration is provisioned via a GitLab CI/CD pipeline and manages to deploy successfully. However, when I then attempt to login into Vault via the UI (as shown below), I get a Microsoft Sign in error message pop-up which includes the following:
AADSTS50011: The redirect URI 'https://{hostname.domain}/ui/vault/auth/oidc/oidc/callback specified in the request does not match the redirect URIs configured for the application '{Azure Tenant Id}'. Make sure the redirect..............
Note: The URL displayed in the error message is somehow missing the port number 8200 which is definitely included in our Azure AD registered app redirect uri configuration.
I have even tried stripping out this same port number from my Terraform code and redeployed, all in an attempt to keep it consistent with the expected URI given in the error message. Yet still, this has failed to yield the desired result and I keep getting the same error.
Any idea what could be the issue?
Found one of the similar issue , please check if that could help .
According to discussion in similar github hashicorp vault issues
Vault’s OIDC provider should validate loopback IP redirect URIs
according to rfc8252 section-7.3 : The authorization server MUST
allow any port to be specified at the time of the request for loopback
IP redirect URIs, to accommodate clients that obtain an available
ephemeral port from the operating system at the time of the request.
This Feat/OIDC loopback redirect dynamic by paladin-devops hashicorp/vault · GitHub
discusses to add checks on OIDC provider to allow for redirect URI to have a dynamic port in the redirect URI if the loopback address is included in the OIDC client
References:
OIDC Provider Loopback Interface Redirection Issue- hashicorp vault (github)
hashicorp vault/OIDC loopback redirect dynamic by paladin-devops
GitHub
Once the admin has consented to my daemon app he is redirected back to my website, but I want to be extra safe and attempt to get the user's tenant from his e-mail address. Is it possible to do so in any way using the common endpoint?
• Yes, you can get the user’s tenant name from the email address it uses to sign in with the ‘/common’ endpoint. Since, you are using a multi-tenant daemon application, the application doesn’t know up front what tenant the user is from, so you can’t send requests to a tenant’s endpoint. Instead, requests are sent to an endpoint that multiplexes across all Azure AD tenants: -
' https://login.microsoftonline.com/common '
• When the Microsoft identity platform receives a request on the /common endpoint, it signs the user in and, therefore, discovers which tenant the user is from. The /common endpoint works with all the authentication protocols supported by the Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation. The sign-in response to the application then contains a token representing the user. The issuer value in the token tells an application what tenant the user is from. When a response returns from the ‘/common’ endpoint, the issuer value in the token corresponds to the user’s tenant.
• The ‘/common’ endpoint is not a tenant and is not an issuer, it’s just a multiplexer. When using ‘/common’, the logic in your application to validate tokens needs to be updated to take this into account. Also, please take note that you cannot query the ‘/common’ endpoint and retrieve the user’s tenant name from its email address as it is passed as a credential grant claim to the Azure AD through the authentication protocols, however the redirection to the Azure AD platform is possible through the ‘/common’ endpoint only when the user logs in to the daemon app web api and the redirection is done internally by identifying the tenant name from the email address of the user.
Please refer this document for more information.
"Once the admin has consented to my daemon app he is redirected back to my website"
The redirect URL must have tenantId in it. 'tenant' is appended as a query parameter to the redirect URL once admin consent permissions.
I'm implementing a Power BI Embedding solution into third party application which uses the same Active Directory as Power BI. However the application has URL with HTTP and not HTTPS.
Now, for getting the authentication token for embedding, I've created Azure AD Web App and I want to add Redirect URI for that application, but it is not allowing me because it is HTTP.
What can be the solution to get authentication token for Azure AD for embedding?
Thank you.
Apps that are registered for Microsoft identity platform has Restrictions on redirect URLs. The redirect URL for web apps and
services must begin with the scheme https, and all redirect URL values must share a single DNS domain. http://localhost is also supported as a redirect URL.
You can create self signed certificates for https domain (for test purpose).If your app runs in Production Environment, it should be signed by a
trusted certificate authority.Check here to know more.
Refer this post for : Trust a self signed cert from IIS
Some networks are configured so that trusted clients and resource providers access IdP via back-channel URL (e.g. http://idp.mycorp.local), while public clients like SPAs access it via front-channel URL (e.g. https://idp.mycorp.com).
Which is the ideal solution for such a network configuration?
We have been experiencing with the following options:
Populate some endpoints (authorization_endpoint, end_session_endpoint) in the discovery document with the front-channel host name regardless of which host name was used for requesting the document;
Configure trusted clients to access IdP via back-channel URL, but switch to using the front-channel URL when it is going to redirect the user agent to IdP.
Sign-in with Microsoft identity provider fails, works with others
I have an Azure AD B2C tenant with a SingIn and SignUp policy that I hope to use
for user management with an Angular2 SPA.
The policy is configured for three identity providers:
Google
Microsoft
Email Signup
When I use the Run Now button in the Azure portal to run this policy, I get the default Sign In dialog, and I can sign in with either Google or Email signin. (By that I mean I get re-directed to my app's redirect page as I expect.) However, when I try to sign in using the Microsoft
provider, I end up at an error page with the following address:
https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The+provided+value+for+the+input+parameter+'redirect_uri'+is+not+valid.+The+expected+value+is+'https://login.live.com/oauth20_desktop.srf'+or+a+URL+which+matches+the+redirect+URI+registered+for+this+client+application.&state=StateProperties%3deyJTSUQiOiJ4LW1zLWNwaW0tcmM6NDcyMmQyNjItOTk1Yi00YTJlLWFmNWUtODkwNDgyODlhMzM0IiwiVElEIjoiM2Y2ZDVmNjAtMDdiNC00ZDA3LWEyZDItN2U3YWQwOWRhOGQ5In0
I see that the problem is related to an invalid redirect_uri. But I thought the redirect_uri was an application-level setting shared by ALL identity provders that I have configured. Why does my redirect_uri setting work for Google and Email signup, but not for Microsoft?
You have to configure your Microsoft application with the right redirect URL.
As stated in the documentation:
Enter https://login.microsoftonline.com/te/{tenant}/oauth2/authresp in the Redirect URIs field. Replace {tenant} with your tenant's name (for example, contosob2c.onmicrosoft.com).
Why you have to do this: (courtesy of Chris Padgett)
The redirect URI that is configured in the Azure AD B2C Portal represents the reply address for your client application. This is so Azure AD B2C can return an ID token to your client application. The redirect URI that is configured in the Application Registration Portal represents the reply address for your Azure AD B2C tenant. This is so the Microsoft Account identity provider can return a security token to your Azure AD B2C tenant.
So, your app is federating authentication to Azure AD B2C.
B2C then further federates to the Microsoft Account identity provider.
So when a user a logs in with a Microsoft account, they are sent back to B2C with a token, which B2C validates.
If all is okay, they are signed in to B2C, and sent back to your app.
So you see that from the point of view of the MSA identity provider, B2C is the client.
So the redirect URL there must point to B2C.
As the document stated, you should Enter https://login.microsoftonline.com/te/{tenant}/oauth2/authresp in the Redirect URIs field.
But I thought the redirect_uri was an application-level setting shared
by ALL identity provders that I have configured. Why does my
redirect_uri setting work for Google and Email signup, but not for
Microsoft?
You're right, the redirect_uri is an applicaiton-level sttings. It should be same in all IDPs redirect URIs. But this Redirec URI is set by Azure. NOT your applicaiton. It means that your can use other IDPs to login to your app with AAD B2C, NOT login to your applicaiton directly. So, the redirect_uris must be https://login.microsoftonline.com/te/{tenant}/oauth2/authresp, not the redirect_uri in your application itself.
URI doesn't equal URL. The redirect URI is just a unique identifier to which Azure AD will redirect the user-agent in an OAuth 2.0 request. It's not redirect URL, Azure AD authentication endpoint https://login.microsoftonline.com/ use redirect URIs to check where it should be responsed. Aslo, it can be same as the URL as the endpoint. Here should be the same I guess.
Summary, you need use the unique redirect URI https://login.microsoftonline.com/te/{tenant}/oauth2/authrespfor all IDPs , not just Microsoft account.
Hope this helps!