I have an on-premise hosted WCF service with REST endpoint which is configured for Anonymous authentication only in IIS. I installed and configured Azure App proxy connector on the server. I am able to contact the service fine with Pass-through authentication, but struggling to authenticate from a console app when Azure AD is chosen as security mechanism. I know I could have pass-through in Azure and turn on for example windows authentication in IIS, but this is unfortunately not an option in this case.
Using a browser, I am able to access the application fine, don't even need to enter credentials, our on-premise AD is connected and synchronized with Azure AD.
I followed this walk-through despite it is not regarding application proxy, and reusing parts of code I am able to get the Access Token for my application, but when I run the http request with Authorization header I don't get the result of service operation.
Using Fiddler I can note the following:
I get http 302 (Found). I can see my Authorization header in request, and in response I get a cookie AzureAppProxyAnalyticCookie
That is followed with http 200 to login.microsoftonline.com
Example I provided link for above works fine so it is clear that I am doing something wrong. Why is Authorization header not accepted and why am I being redirected to logon page?
Thanks in advance
This is working for another service, have no idea what was wrong with the first one, but suspecting something with DNS on local server. Won't be spending more time on this, point is that I shouldn't have experienced the redirect at all, although browser handled it and managed to get me authenticated.
Related
I have a .NET Core Web API hosted in Azure App Service, with API Management in front of it.
I have added the IP of API Management to be allowed in inbound traffic to my App Service:
If i send a request without a subscription key to the API Management endpoint i get
{
"statusCode": 401,
"message": "Access denied due to missing subscription key. Make sure to include subscription key when making requests to an API."
}
When i add subscription key and send request through postman, it will just be infinitely loading unless i set a timeout.
I can send requests directly to the App Service endpoint url (by temporarily adding my IP to allowed IP addresses in network settings) and it works perfectly fine, and when i check logstream i can see logs that my request was successfully handled in my middleware.
But when i send requests to the API Management endpoint, there are no logs in the App Service logstream from my middleware.
When i check the logs in API Management i find this error, which doesn't help me much:
Any idea what could cause this? Maybe i've done something wrong with how i've set up App Service / API Management.
Ugh, found the mistake. I had accidentally set the "Web service URL" in API Management settings to the API Management URL instead of the App service URL, so it was essentially trying to send requests to itself, perhaps resulting in an endless loop.
Is there a way to use the native WindowsIdentity/WindowsPrincipal inside of a C# application running on a corporate domain to be able to request a SAML token from the domain's ADFS server so that the C# application can then make subsequent calls to WS-Federation calls in a service provider that has been federated with the ADFS server?
Seems like we would use WIF to contact the ADFS server to get a token. Is there a way to supply a Kerberos ticket to the WIF, rather than using a username/password?
Looking at WindowsIdentity.GetCurrent() I can see that the user is logged in using kerberos, but don't see how to configure the WIF call to ADFS to use kerberos to automatically get a SAML token without a username/password set of credentials.
Does https://blogs.msdn.microsoft.com/alikl/2011/09/30/how-to-use-ad-fs-endpoints-when-developing-claims-aware-wcf-services-using-wif/ help?
You should make sure you have an endpoint enabled that can do windows integrated auth via kerberos enabled. Something like /adfs/services/trust/2005/windowstransport or /adfs/services/trust/13/windowstransport . You can check that via parsing the /adfs/services/trust/mex endpoint. Occasionally some of these endpoints are disabled by a sysadmin.
Using a kerberos ticket as the credential for the endpoint means your app needs to be running on corpnet with access to domain controllers so it can obtain a ticket for AD FS. If the app use is not required outside corpnet this might be OK for you. Else you need to consider how the app behaves/authenticates inside and outside corpnet.
Have a look at https://www.microsoft.com/en-gb/download/details.aspx?id=4451 for samples but they'll need modifying based on version of WIF you plan to use as outlined in https://learn.microsoft.com/en-us/dotnet/framework/security/guidelines-for-migrating-an-application-built-using-wif-3-5-to-wif-4-5
Lastly you should consider if its possible to use OpenID Connect and OAuth2.0 instead of WS-Federation/WS-Trust in your scenario. If yes, you should review the information at https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers
I'm having this issue with my custom integration to Salesforce from an Azure function right now. For some reason when I test locally and use the local endpoint with Postman I can authenticate with Salesforce just fine but when I publish my Azure function to the cloud and I swap out the endpoint my authentication fails for Salesforce. The exact error message being authentication failure.
At first I thought there must be something wrong with my IP settings for the connected app in Salesforce but I've tested setting Relax IP Settings as well as not defining a Trusted IP Range for OAuth Web server flow and still no success. Here are a couple of screenshots of my settings.
Any ideas why I can authenticate locally but not once I publish to my cloud service in Azure? (I'm using SalesForceSharp to authenticate if that makes any difference)
Finally figured out what the disconnect between my cloud environment (Azure) and Salesforce was when I dug into my login history in Salesforce and found attempts to login from an insecure location.
Apparently different SSL/TLS defaults are setup for local versus cloud environments.
https://github.com/Azure/Azure-Functions/issues/482
Once I input this line at the top of my function and published everything got back to working again.
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
I have been looking at using Open ID Connect as a third party authentication provider for a Web API application. The flow is as follows:
Users log in through UIWebView with iPhone application to the provider URL from https://daehwa.azurewebsites.net/api/Account/ExternalLogins?returnUrl=%2F&generateState=true
This redirects to my third party site which supports Open ID Connect authentication.
User logs in through this site and redirects back to my site with a token in the fragment of the URL in the form of #id_token=xxxxx
Looking at the following SO article: asp.net web api 2: how to login with external authentication services?
I then should be able to call /api/Account/UserInfo however this always returns 401 Unauthorized. Setting the Authorization: Bearer token doesn't seem to help either and always return unauthorized even when trying to call /api/Account/RegisterExternal.
Just to give you some more information about what I am trying to do I would like to either create an account or at least make subsequent OAuth calls to retrieve their email address and their display name ideally avoiding requesting this information from the user again. However for now I just want the authentication to actually work!
I would really appreciate any help anyone can provide. I'm new to third party auth and I feel as though I am missing something key. I think that my return url is the issue and my server needs to process this token and issue me with another one but not too sure.
Thanks,
Gerard
I'm currently developing a web api, with WCF web api, which allows me to write restful apis. One concern I have is security. For this reason I decided to protect my api with the OAuth protocol which works very good. However, the team got to the conclusion that our own applications shouldn't be authorized by oauth, instead they sould be authorized by http basic, meaning that the client application should send username and password.
So I have 2 questions:
How can I set up WCF Web Api to work with SSL, I'm using Web Api preview 6, and the project is a MVC3 application?
I have an operation handler which takes care of the creation of IPrincipal from the client access token, and then injects it into the operation parameters, so I can access the user's info. I would like to have in the same operation handler a condition where I could check if the authorization scheme is OAuth or http basic, and then in the case of http basic extract the user's credentials and authenticate that specific user against my data base, if authentication is successful create an IPrincipal and inject it to the operation parameters. However, as I see it, everytime an application using http basic requests something to the api, I would have to go to the data base and authenticate. So my question is: Am I in the right path, or this could be accomplished in some other way?
Any answers would be appreciate it. Thank you in advanced!
You setup SSL for WCF Web API just like you would any other WCF service exposed over HTTPS. If you are hosted in IIS, then you need to configure a site binding for HTTPS. If you are self hosted, then the configuration is bit more involved. See http://msdn.microsoft.com/en-us/library/ms733768.aspx for all of the details.
To handle basic auth against a custom identity provider you would typically use a custom authz module when hosted in IIS. See [http://custombasicauth.codeplex.com/] for an example of how to do this. If you are self hosted then you can use a custom username passworld validator. See http://msdn.microsoft.com/en-us/library/aa702565.aspx for details.
Yes, I believe you are correct that every request will require authentication unless you establish some sort of session-like semantics.
Hope this helps.