We have an application that is reachable through a specific URL when connected from our office public IP, and that is reachable through another specific URL when outside the office with a VPN.
We managed to set up the oAuth2 SSO for the first usecase and I was wondering if there was any way to add the second URL, so that our users working through the VPN could also log in with the SSO.
Couldn't find a way to do it so far, if you have any clue.
Thanks !
As juunas said, when you set Redirect URIs in Azure App registration, you could add multiple redirect urls.
And when you use OAuth2 SSO, here such as using OpenID Connect flow, you could specify different redirect_uri when you authenticate the user.
Thanks for your answer, the second redirect URI configured in the Azure App was redirecting us to the first one specified, after hitting the SSO connection button. I guess we found something in the app that was forcing this redirection, we'll try to remove this setting on Monday.
Thanks for you help,
Steven
Related
I wasn't exactly sure how to best describe the title of the question for the issue I am having, anyways this is the problem I am encountering, I have searched for a couple of hours and could not find an answer.
I am building and app which is passing through the Azure AD sign in and redirecting back after a successful handshake. All works fine when using https://localhost:port as my RedirectURI in Azure, for example:
Under Web Redirect URIs this following works just fine:
https://localhost:7280/signin-oidc
I login with my AD credentials and I am redirected back to my app's landing page, so all good there.
The problem is however, when I use the following in the hosts file, I am just redirected back to the Azure AD sign in page, even though when I check the azure sign in logs, it states the login was successful.
Question: Is it possible to use a custom URI using the hosts file in a local development environment, when developing an app passing through an Azure sign in? Or am I restricted to using https://localhost:portNumber for my web redirectURIs? Thanks in advance.
Here is the hosts file and the web RedirectURIs in Azure. As mentioned earlier, https://localhost:port works fine. Note: I already have an SSL Certificate for the local development environment which is fine.
My hosts file:
127.0.0.1 dev.operations.co.uk
My web redirectUri(s) in Azure which I have tested:
https://dev.operations.co.uk/signin-oidc
https://dev.operations.co.uk/
I have multiple sub-domains listed in a SaaS app. The app provides options to configure SSO with Onelogin, however it provides the option to Enter only one SAML Endpoint(to which users will be redirected) and One certificate.
In this specific case with Onelogin, the certificate with One login is same across different apps that are setup at Onelogin, however each app has a different SAML endpoint. This makes it impossible to configure SSO with multiple sub-domains of the SAML app.
Tried using SAML Connectors (Advanced) in Onelogin, however when multiple connectors are setup each still has a different SAML endpoint.
Any help in configuring an app in Onelogin using same SAML Endpoint would be very helpful.
You're at the mercy of your SP here. If it only supports one IdP, then there's nothing you can put in place in Onelogin to mitigate that. To extend #todaynowork's answer above, the RelayState parameter might be of use to you but your SP will need to support it. The RelayState parameter allows the SAML request to include the resource your user was initially requesting. When the SAML response is verified at the ACS URL, you can then use the RelayState parameter to redirect the user to their requested resource across any of the subdomains. Assuming your SP side sessions are consistent across all subdomains, that could work for you.
Suggest you use the SP initial SSO. That support deep link. Deep link means you could pass the return url while you do auth request. After success login, it will return to 'return url' you passed.
Might seem a silly question, but Microsoft's documentation isn't very beginner friendly, I think. It uses as examples "http://localhost:31544" for the sign-on url and "http://MyFirstAADApp" for the redirect URI, but although I understand what a local host is I can't figure out what exactly the numbers on it are and how I define them for my application, and absolutely zero clue of what the redirect URI is supposed to do for a native application and how should I define a URI for my own.
To be more clear on what kind of app I'm trying to add, I merely want to acess the Office 365 management API tools and get some data from it, so I imagine a native app would fulfill my needs for now. Registering the app on Azure AD is required to do so according to Microsoft's documentation.
So expanding on the title, how to define an URI for my native app is what I would mainly like to know. Some further clarification on what exactly is the purpose of this URI as well as to how to use and/or define a localhost URL for an Web app would also be much appreciated.
I know this is ancient, but I don't see a satisfying answer here, and maybe someone will come across this and find it useful. To answer the question asked, unless you're going to work outside of the default MSAL handling of the server responses, and I don't expect you would from your description, I'd just go ahead and use the default:
https://login.microsoftonline.com/common/oauth2/nativeclient
When you go into the Azure AD portal, go to your application and, from the Overview, select the "Set RedirectURL" option, you'll add a platform and select the "Mobile and Desktop Applications" and you'll be provided with the choice of 3 URLs to choose from. My understanding is this is just there for custom handling of authorization tokens and is telling MS where to send those tokens. The MSAL library functions seem to use this link as well, so they're probably handling this in the backend.
I agree with the OP though, the MS docs are severely lacking for newcomers and I wasn't able to find an end-to-end description of what needs to happen to get, in my case, a desktop application to send email through Office365 using 2FA. I would forge ahead as best I could until I hit the next error, then explore that, sort it, then slam into the next one. Rinse and repeat. This was made extra tedious as I had to go through a 3rd party IT group to get the 2FA access codes every time I wanted to test.
Best of luck, hope this helps someone!
how to define an URI for my native app is what I would mainly like to
know.
You should provide a Redirect URI that is unique to your application as it will return to this URI when authentication is complete.
In your application, you will need to add a class level variables that are required for the authentication flow, include ClientId and Redirect URI.
Here is the diagram:
Native application makes a request to the authorization endpoint in Azure AD, this request includes the Application IP ,Redirect URI and application ID URI for the web api.
After user signed in, Azure AD issues an authorization code response back to the client application's redirect URI. After that, the client application stops browser interaction and extracts the authorization code from the response.
Then the client app use this code to sends a request to Azure AD's token endpoint. upon successful validation, Azure AD returns two tokens.
Over HTTPS, the client app uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. The web API then validates the JWT token, and if validation is successful, returns the desired resource.
More information about it, please refer to this article.
For native you can set redirect to be equal to the Application ID URI, which now defaults to look like //app:{ApplicationId}
Redirect uri be starts with SSL URL, so select your project, enable SSL URL and use this auto generated SSL URL (for example : https://localhost:port#) as redirect uri , same to be updated in the azure app registration as additional redirect URIs
I have an IIS website on a server internal to my domain that is also published via azure application proxy, which is secured using windows authentication. Our AD structure is hosted locally and published to Azure AD via AD connect.
Users visiting from outside the domain are authenticated first via the login.microsoftonline.com page.
My problem is that users external to the domain are on shared devices and need to change users occasionally, and I can't figure out how to do that.
I have read that navigating to an url like https://login.microsoftonline.com/{tenant id}/oauth2/logout?client_id={client id}&post_logout_redirect_uri={???} is supposed to achieve this, but after arriving at the login page and logging in as a different user, when we return to the site the user turns out not to be the user that authenticated, but remains the same user as before the attempt to change the user.
I have also read that deleting the cookies named like AzureAppProxyUserSessionCookie, AzureAppProxyAnalyticCookie and AzureAppProxyAccessCookie can help, but doing so does not seem to make any difference.
I thought that perhaps the browser was auto-authenticating or pre filling in forms etc, but turning those features off does not affect anything.
My questions are:
Are any log-off / log-on via Azure AD event logs kept that I can view, and if so, where?
How are you meant to log-off for my scenario?
I have implemented AAD authentication in one of my webapp, using OWIN. everything is working as expected on dev environment but it is not working on PROD. At login it goes to AAD page, it authenticate users and it redirects back to my registered page, but register page is not opening at all. In title it show working only. I am completely lost, how to resolve this, Please help me to resolve the same.
Thanks in advance!
I got the solution for this. The issue was - to store the Tokens the Owin context created a local db (AzureTokenCache.mdf and .ldf files) in App_Data folder. This uses SQL express. Now we all know that using PaaS we cannot use any Software. Hence my authentication failed every time saying that error connecting to database. I moved everything to SQL Azure and it worked for me.