We need help in implementation of MS Login and SSO together on same azure application and we are facing below challenges.
Currently we have implemented MSLogin and SSO authentication with independent Azure application and it is working as expected.
But now customer is expecting that instead of configuring the MSLogin and SSO authentication setting independently in azure for two application can we have it with one azure application only.
Based on above scenario I have following question:
Can we implement MSLogin and SSO authentication together? If any lead would be highly appreciated.
Currently I have some partial implementation of the above approach but facing challenge with redirect URL.
Issue: If I configure the same application for MSLogin & SSO authentication then
For MSLogin its mandatory for us to provide the redirect URL and if we don’t pass it then MSLogin authentication not working.
If we pass this redirect url then the reply URL which we have set for SSO is not getting triggered and always redirecting to MSLogin redirect URL only through azure cloud (don’t have any control).
Any help on above issue is highly appreciated.
• The redirect URL option is featured with those apps who have custom app registrations other than that of Azure apps specified in the gallery for whom the redirect URL is already configured inbuilt to be of Azure sign out page.
• That’s why, the sign out URL is of utmost importance in enterprise applications from where the Identity signing out of that platform is confirmed. Thus, you can check the following method of using a state parameter while configuring the redirect URLs might be useful.
• Create a "shared" redirect URI per application to process the security tokens you receive from the authorization endpoint.
• Your application can send application-specific parameters (such as subdomain URL where the user originated or anything like branding information) in the state parameter. When using a state parameter, guard against CSRF protection as specified in section 10.12 of RFC 6749).
• The application-specific parameters will include all the information needed for the application to render the correct experience for the user, that is, construct the appropriate application state. The Azure AD authorization endpoint strips HTML from the state parameter so make sure you are not passing HTML content in this parameter.
• When Azure AD sends a response to the "shared" redirect URI, it will send the state parameter back to the application.
• The application can then use the value in the state parameter to determine which URL to further send the user to. Make sure you validate for CSRF protection.
• Also, the client must protect these parameters by encrypting the state or verifying it by some means as you are using a personal Microsoft login for authentication purposes which means personal Microsoft accounts will be able to access the application configured in Azure AD, so please validate the domain name in the redirect URI against the token.
Please find the below links for more information: -
https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-microsoft
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 would like to secure my Azure WebApi with 3rd party providers (FB, G+... I basically just need a valid email). Was looking at Auth0 and seems like it will do the thing paired with Jwt middleware in web api project, but I was wondering if the same can be done using Azure only.
Azure Web App authentication confused me a bit - it does not seem to give anything to my Asp.Net web app. I still have to configure all the middleware in Startup.cs and the app still works fine if I completely turn authentication off.
I could do the same thing Auth0 does - issue my own Jwt tokens based on access tokens from FB or G+ - but would like to avoid that.
Could you please point me to the right direction?
You have a couple options:
App Service Authentication
Configure the authentication via middle ware
App Service Authentication
The App Service Authentication does not require any code inside your application because your App Service has a gateway that inspects request for authorization. Depending on the setting you can either secure the entire site or secure individual resources (by using the [Authorize] attribute on the endpoint in MVC/WebAPI).
With the latest release you can control authorization on a site by site basis including manually triggering the sign in by navigating the user to the <yoursiteurl>/.auth/login/<provider>. By defualt the token store is enabled so you can make a request to <yoursiteurl>/.auth/me and get back information from the provider.
Middleware Authentication
This is the default way authorization happens in the Single Page ASP.NET Template. The middleware authentication uses OAuth/OpenId to secure the resources. This option does it at the application layer instead of at the gateway. If you are using ASP.NET Identity (from the single page project template) the email from the persons log in will automatically be stored in the Users table. The tutorial in the link above gives lots of details on how to get it working.
Make sure you use the [Authorize] attribute to trigger the Authorization in either case.
Hope that helps you get started in the right direction.
I currently have a MVC4 home-grown secure token service (STS) that communicates with our own authentication database. All is working just fine with this setup. As a new feature I need to add the ability for single sign on (SSO) through ADFS2 for those users that are on the domain (bypasses the current un/pw screen, and they're just 'in'). To be clear there really are 3 different login possibilities that need to be handled: domain user (SSO), domain credentials (domain user not on domain entering their domain un/pw), and the original un/pw auth from database. Knowing what I know about adding web.config settings to the relying application to wire up the STS, how would I wire up both wsFederation passive redirect options (current redirect to STS for un/pw, and the ADFS option)? Is this something that would have to be handled in code, through an overloaded class such as WSFederationAuthenticationModule? What would be the best way to handle what I want? Any code examples? Thanks for your time!
You just have your login screen on your custom STS and two additional buttons, "login with ADFS" or "login as domain user". Both buttons are redirects to two other STSes your STS is federated with (your STS plays then role of either an Identity Providing STS or a Relying STS).
That is not very complicated. What you need is to create two SignInRequestMessages and using their WriteQueryString build two urls to two different STSes. Another way would be to use the WSFederationAuthenticationModule::CreateSignInRequest method.
http://msdn.microsoft.com/en-us/library/system.identitymodel.services.signinrequestmessage(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/system.identitymodel.services.wsfederationauthenticationmodule.createsigninrequest(v=vs.110).aspx
Consuming responses is tricker as you need a single uri (or two different uris) that play an endpoint roles. In the uri you need a token receiver and try to create a token out of the SAML sent by the provider.
If you peek at the source of a community replacement of the wif:FederatedPassiveSignIn method I wrote once, you will get the idea
http://code.google.com/p/net45federatedpassivesignin/source/browse/trunk/+net45federatedpassivesignin+--username+wzychla#gmail.com/Community.IdentityModel.Web/Controls/CommunityFederatedPassiveSignIn.cs?spec=svn6&r=6
(at least half of the code is responsible for the WebForms user control infrastructure but the other half is what you are looking for)
Unfortunately also, such custom mixed scenario is not easily handled with just the configuration of federation modules.
I have successfully linked ACS to ADFS and our website user's authenticate against ADFS without issue.
I also have legacy sites that authenticate directly against AD via custom code and IAG.
We would like the users of the legacy site, once authenticated, to bypass having to login again to enter our new sites. Removing IAG is not an option at this moment.
I have the ability to add additional pages to the legacy site and I can create addition IP's in ACS. My attempt so far has been to create a self signed cert, generate a federatedmetdata.xml based on that cert file and import that into ACS. That went well. Then I wanted to try and create the WSResponse and claims for the WSignin1.0 request and post that to ACS using the same cert I used to create the metadata file. That action would occur from the legacy site. That has not went so well as I usually receive a HTTP error code of 500 with the "ACS20001: An error occurred while processing a WS-Federation sign-in response" from ACS.
Basically I would like to know if what i am doing is feasible? , or perhaps there is a better way given the constraint of IAG, or if I am close and should continue down the path I am on.