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.
Related
I want to import the wsdl from some private server on azure. They (server owners) have issued us a certificate and also have whitelisted the outbound IP's of my Azure service. I added private key certificate on my Azure service.
After that I followed this article and created a new API management instance and tried to import the wsdl file from their server URL but its giving me following error "Unable to download specified file. Please ensure the URL is valid and file is publicly accessible."
It was quiet easy if I had a VM and with whitelisted IP's. I could've used SoapUI testing tool on the whitelisted IP machine in which I can provide the p12/pkc certificate as well, but I'm not able to do it on azure. Any help will be appreciated!
Since only the outbound IPs of your App Service have been whitelisted, the request to the private server can only come from there. Both APIM (and the CORS proxy used to load the WSDL) have different IPs.
One way to approach this would be to have a simple proxy app on your App Service which proxies requests to the private server (with some security of course) and use that URL to load the WSDL. Also, in APIM, you would have set the backend of your imported API to the proxy endpoint.
Another approach would be to whitelist your APIM IP instead but loading the WSDL would still fail because of the CORS proxy used. In this case, you could either
Acquire the WSDL file manually and upload it
Create an API in APIM which just returns the WSDL
Also, do note that the outbound IPs for both APIM and App Service may change with specific configuration changes.
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.
We have created a downloading client-service model application in which a WCF service is hosted on one of our servers and the client application is distributed among the partners.
Partners are provided with unique pin using which they can authenticate themselves with the WCF service and can place requests for downloading to the WCF Service.
The clients connect to the WCF Service through Windows Azure Service Bus within which we have created a namespace using which client applications can connect to the service.
Every namespace has a Default Issuer and Default Key. We have embedded this Default key in our code when connecting to the service bus.
Somebody told me that the key needs to be secured and you need to get the application signed in order to protect the embedded key. Is that true?
Do we really need to secure this key?
If yes then how? and Is there a way we can simply provide authentication in Service Bus which identifies the clients from their pins and and allows only a set of people to access the service bus namespace?
OR
I'm uselessly getting worried on such points? :)
We are using Service Bus Relay.
I have been reading about SAS and ACS and it seems according to the documentation that SAS is not supported for Relays. Following is the link:
"Support for Service Bus relays will be added in the near future."
http://msdn.microsoft.com/en-us/library/windowsazure/dn170477.aspx
I am unable to understand how to use ACS for authenticating clients. The information provided in the Windows Azure documentation are all bouncers for me and I can not relate them to anything no matter how hard I try.
If somebody has any information for my concerns then please help me with proper links and guidance.
Thanks!
EDIT!!!
I have been searching on this and the following link provides a methodology for creating an unauthenticated client:
http://msdn.microsoft.com/en-us/library/microsoft.servicebus.nettcprelaybinding.aspx
by using following tag in my client App.Config
<security relayClientAuthenticationType="None" />
I have tried this, but getting the below error:
"Generic: There was an authorization failure. Make sure you have specified the correct SharedSecret, SimpleWebToken, SharedAccessSignature, or Saml transport client credentials. MissingToken: Relay security token is required."
I'm looking more about this error. But few questions arise.
If we make the azure service bus accessible without authentication, can somebody simply misuse the service bus for their own advantage?
Do we really need to secure this key?
You store Issuer and Default Key on your server side.
To authorize on the Azure service bus, Service Bus WCF endpoint uses the Issuer and Default Key to create a token that will be signed with the Default Key that means that Default Key will never be sent to Azure.
Is there a way we can simply provide authentication in Service Bus
which identifies the clients from their pins and and allows only a set
of people to access the service bus namespace? OR I'm uselessly
getting worried on such points?
As far as I understood you have already implemented some kind of security on the WCF side.
There is another one way of doing that. You can use ACS to authentificate Clients. By Default Azure relay Service provides Support for the Simple Web Tokens.
Here is the workflow:
Client send UserName/Password( or UserName/Key) to the ACS.
ACS validates whether the credentials are valid.
ACS send the SWT token back to the Client.
Client packs the SWT token onto the HTTP request(for instance into
headers)
Client sends a request to the Web Service with the token in Header.
WCF web Service recieves the token and validates the token with the
secured shared key that was provided from ACS Namespace.(note that
this key is not sent during the communication it has to be manually
copied from the ACS Portal to the web Service config file)
If token is valid then web Service sends data to the Client.
There's a load of stuff to cover, so I'll try to keep it structured, as all good programmers should.. bear with me.
My Environment
.NET 3.5 SP1 Smart Client
Uses WCF+SOAP over HTTP to communicate to server for business logic / data access
Typically uses a custom (username+password) or Windows authentication scheme
Current work aims to extend to include a new Claims-based authentication scheme to facilitate SSO with ADFS
So far...
Main service endpoints using ws2007FederationHttpBinding bindings, configuration set up with Message security via trust/13/issuedtokenmixedsymmetricbasic256 ADFS 2.0 endpoint
Issuer endpoint configured with IssuedTokenOverTransport to HTTPS trust/13/usernamemixed ADFS 2.0 endpoint
Service has federateServiceHostConfiguration service behaviour specified
Created temporary certificate authority (CA) cert
Created temporary certificate signed by CA
Installed certificate (including private key) and made available to IIS app pool process account
Updated service WCF config to use X509 certificate
Client modified with new app’s own Client scheme/mode, programmatically sets up channel factory to ignore errors caused by temporary certificate and disables certificate revocation checks
Username/password credentials are successfully added (via standard WCF ClientCredentials object) to SOAP envelope of token requests
Token is successfully generated by usernamemixed endpoint and is returned to the client
My problem
Immediately following the token being issued, the subsequent call to issuedtokenmixedsymmetricbasic256 endpoint fails with generic error message that the security of the message could not be validated. Inspection of the SOAP envelope result gives no information at all beyond a simple ‘failed’ result enumeration value
Full tracing has been enabled on ADFS 2.0 server, but no events are logged at all in Event Log or event traces to further diagnose
Unable to configure to work in a federated manner thus far; token is successfully issues over usernamemixed endpoint in the ‘test’ environment (the internal ADFS server rather than a remote one). Use of the ‘live’ environment gives a simple unexplained 401 HTTP status code whether using usernamemixed with confirmed and valid credentials, or windowsmixed, when trying to obtain a token
Generally: Resources from Microsoft or other sources are either very scarce, very specific to one situation, and in a couple of cases, completely wrong or misleading
So ask a question already, doofus
Why does the call the issuedtokenmixedsymmetricbasic256 that WCF makes after getting the token fail? How can I diagnose the result? Other than what I've already done - enabling all trace flags in the service host config, checking the event log and event tracing data, what can I do?
Note, if you're about to suggest a link to a screencast/guide/blog/seemingly all-encompassing MSDN article, please stop. I believe I have found them all, tried them all, and what I need at this point - if you can help me please - is an answer to the above question. Not a general resource.
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.