I have client apps that talk to my silverlight application and its web services. So the client app is running on the client machine and making calls directly to the silverlight app running on the machine and also making web service calls.
I want the usernames/password security to be handled by the 3rd party client app.
Any idea how I can do this?
I'd try the Application Scenario's, Guidelines and How Tos sections of this CodePlex Link. You should be able to find a scenario that matches closely to yours and follow the guidelines and configuration to get yourself going.
If I've understood this correctly, the client application would pass a username/password to your silverlight app which would require a wsHttpBinding that has clientCredentials="Username". You would need to be able to authenticate this against a user store configured on your server, for example you could configure a SQL Server provider.
I'm not sure how your 3rd party client app works, but you would require a seperate security configuration for that communication. You could use a less secure binding if the apps were on the same machine and possibly use clientCredentials="Windows"/"None"/"Basic".
Difficult to advise further without knowing your exact situation. What do you have so far?
Related
I am implementing a WebApp in our company's intranet with Blazor WebAssembly. I need to make API-Calls to our DevOps Server hosted in our intranet and need to use Windows Authentication to access the API. In the former used WPF Client it was enough to just add the UseDefaultCredentials-Flag on the HttpClient, but that does not work in WebAssembly anymore since the App is running in the browser. The Microsoft Docs state We don't recommend using Windows Authentication with Blazor Webassembly, but not recommend does not mean not support, so it has to be possible somehow, to attach the current App-User's Windows Credentials(Token) to the API Call. Unfortunately there exists no example on the docs page on how to implement this and I have not found any code on how to tackle this, although on some forums people wrote that it is possible, but did not include the How in their comments.
I am using .NET5 for both Server and Client and need to make the Api-Call with Windows Authentication from the Client, not the Server as most examples are using it, as my Server-Project uses the same User for all Requests but I need the User of the Client-Project.
Any kind of help is appreciated.
I have been struggling with setting up an iOS (Objective-C) app which utilizes the Service Management APIs. I've successfully was able to get Storage API calls working fine, but from what I'm reading, one big difference between the two Azure APIs seems to be a matter of authentication. For reference, what I'd ideally like to do is setup a simple API call to list the Hosted Services accounts in an app (eventually geared for public deployment).
According to the API Azure documentation, the Service Management APIs require a management certificate (.cer) to be uploaded and then for the client to utilize that cert to authenticate the request. My hunch is that this will prevent an app like the one I want to create from being feasible by any means, since public users with devices containing the downloaded app won't have that cert or the ability to attach it programatically in the objective-c code.
Is my hunch correct on this? Is this a forlorn idea that should not be pursued? I would think for this to be possible, the user would be required to upload their device's cert file to Azure somehow, and then to somehow have the app use this cert for authentication. I'm a bit lost on where to even begin on that, even if it is possible. :(
Any helpful info would be greatly appreciated. I have a lot of experience in the iOS side of things, but specifically in authentication/certificates of this type, I unfortunately have minimal experience.
Thanks in advance!!
-Vincent
Actually, I have an app that does exactly what you're talking about. CloudTools for Windows Azure is an iOS app that uses the Azure Management Service API to perform Azure management. It's been on iTunes for over a year.
Your question is somewhat broad, but I can tell you that the certificate issues were by far the biggest issues in designing/developing the app. You can't store the certificate in keychain, because keychain works in a manner such as this: a) you request a remote url that requires a certificate; b) that url tells you that it needs a certificate and c) keychain provides an appropriate certificate. It's a multi-request process. That won't work for Azure, because Azure service management APIs expect the initial call to include the certificate.
I require the users to add their certificate through iTunes File Sharing (steps here). Of course, they have to upload the public key portion to Azure. Then, I provide the certificate and private key with each request. I use the HTTP library ASIHttpRequest, although I believe that the latest (iOS 5.x) Apple libraries have similar functionality.
I'd be happy to provide any further details if you have any follow-up questions.
With Windows Azure, if you are using Service Management API then you really need to have certificate based authentication to create a SSL tunnel between your machine which is requesting the connection and Windows Azure Management Portal. I am not sure how wide your iOS application distribution is.
My first thought is that why would you want to deploy Windows Azure application from an iOS application, are you going to build application in iOS devices and deploy? Windows Azure Application deployment is mostly done on client machines so, Azure application management on iOS is great idea, however Application deployment from iOS not sure why. May be you are on something big here.. In both cases you really need Service Management Certificate on iOS device. If it is an enterprise app where you can let users to install Service Management certificate, it would be easier for iOS devices to use Service Mgmt API.
So if you want to use Service Management API from a client iOS app, I think the best solution will be to have WCF service hosted in Windows Azure which is configured to directly connect with your Windows Azure Portal. And from your iOS app, you just make call to your WCF service. This is very popular method to access service management API (through WCF Service) from any client app (WP7, iOS, Android) and the client side code is very light. On other hand you may need to pay to host a WCF service on Windows Azure.
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.
I have created and tested a WCF REST service that is protected with SSL and Windows Authentication through IIS 7. I have also created and tested a pure html/javascript web client that is hosted in IIS 7 that is protected with SSL and Windows Authentication -- same server, different "site" within IIS. The REST service is not public, but the web client is.
Without security, everything works beautifully, but now we are ready for field testing and security must be implemented.
My end goal is to have the user visit mywebclient.com and authenticate using their Active Directory accounts. Initially I thought it would be safe to leave the service calls from the client to the REST service unprotected (since the traffic from the web client to the web service would be internal), but this does not protect us from an internal attacker. Also, in the future, the REST services will be available to handhelds through native applications.
I've tried to gain as much information on this subject as possible, but every piece of Microsoft documentation contains client examples written in .NET.
How can I share the security context between these sites without converting the web client to a .NET-based application? Could this be accomplished by combining the web client and service into one IIS "site"?
Edit: If the client and service exist in the same app pool, does that mean they could share authentication information between client and server processes?
I am writing a Silverlight application that will be both reading and writing data to a serverside database via some WCF web services.
What is the best way to secure these web services?
My goal is to make sure the services can't be called by other applications and potentially spammed with requests to add items to the database. Only the Silverlight application needs to be able to access them.
Don is absolutely right that there's no foolproof way of making sure that the client is a Silverlight application.
However, I think you're asking more about the following: Can I make sure that only people I trust connect to the service.
The answer here is (basically) a yes, or at least we have standardized ways of doing this.
You're typically going to want to consider a couple of different approaches:
Transport level security. Has somebody tampered with the traffic? We use SSL for this.
Authentication. Am I talking to someone I trust? Here, we'll typically use one of the authentication mechanisms (Forms Auth, say). You can use Forms Authentication to secure both Silverlight (actually the page that Silverlight resides on) and the WCF services. Confusingly, SSL can be used (though rarely is because it's a pain in the neck) for authentication.
In general, you can't assume anything about the client. If you try to keep non-Silverlight apps from hitting your site, a malicious client can easily pretend to be a Silverlight app, and you're back to square one.
That is to say, this is not an effective way to secure a server. To secure your server, assume that any and all clients will hit your site, and start from there.
Edit:
Let me amend that to say that if you want to get into the world of mutual authentication, you can set up a PKI to manage certs, issue user certs for all your users, and then you know who your users are. Still, one of them might be malicious (and talented) and inject a cert into another client.