We are designing a new N-tier project where clients calling WCF services. In a previous project i worked on, we used implemented own classes for System.ServiceModel.ClientCredentialsSecurityTokenManager and System.ServiceModel.Description.ClientCredentials (which rely all on the System.IdentityModel somehwere) bound those credentials to the Service Endpoint and used a STS check if the user has the rights to perform the specified operation on the service. All users had at least Windows Vista - so far so good.
Now, we wanted to use a similar approach. But this is then the customer kicks in: they almost all have Windows XP machines, but Windows Identity Model cannot be installed on XP (not supported). So, before we are starting to design in a totally wrong direction, I am better of asking for your advice.
EDIT
Ok, i installed a new VM with Windows XP and all the needed assemblies seem to be available, so it might just have been a false alarm then!?
Slightly confused about the XP angle. Do you mean you need to develop the application on XP or host it on XP or that XP users will simply use a browser to access a claims-aware application?
If the latter, it's not an issue.
Related
We have an application that uses a REST service from our customer through XML requests and responses. It runs on a Motorola (now Zebra) MC3190 Handheld Computer running Windows CE 6.0.
Last week they decided to publish the service using HTTPS and since then my application stopped being able to use the service. I can't even get pass the login.
Now, I've already tried to install on the device all the certificates available from their HTTPS URL and also this solution; but none of it worked.
The strangest thing is that when running the same application on a Desktop environment (Windows 10, for example), everything works like a charm.
I've already ran out of ideas of what to do, and I hope you guys can give me something to work with.
I assume the HTTPS site uses a SHA2 certificate (most, if not all, do these days).
Our experience is that Windows CE only supports SHA1 certificates (details here), so that might be the issue.
We have an application that needs get from an Administrator account to another limited account and the other way around. Currently we are setting the auto logon in the registry, then reboot the machine. This takes up to 3 reboots as the machines are EWF enabled. Our customer support just cannot sit around and wait for the remote machines to reboot while there's an angry customer on the phone.
We have a windows service and a ui running on the machines (written in C#). Most of them are windows 7, but some are windows xp and windows 8.
I was wondering if anybody here knows a way to maybe trick windows into thinking it was just rebooted and auto log into an account. Anybody know of anything? I do know there are tricky ways to log into an account automatically from the login screen, but as far as I understand that's going to require writing a module to replace GINA in windows XP, and in windows vista and up, since GINA was replaced with a "Content Provider", writing a Content Provider or something, both of which seem overkill, but a possible future solution. Any ideas?
NOTE: We are not switching between accounts so that the application can run a process under that account, we are switching between accounts so real people have either administrative access or limited access to the computer. Hope that makes it a little more clear
If you have an application that needs to run between other users and an administrator, you should be creating a launcher application. The launcher application should be using Process.Start() to start your application. You can supply ProcessStartInfo arguments to Process.Start() so that you can run the application using different credentials.
Here'some help. For Xp, there's a simple registry key that does it (search google for AutoLogon), for Win7, it's a bit more complex. See this topic:
http://answers.microsoft.com/en-us/windows/forum/windows_7-security/how-to-turn-on-automatic-logon-in-windows-7/99d4fe75-3f22-499b-85fc-c7a2c4f728af
I think we had something like this running somewhere, but it wasn't my task and the collegue is on vacation this week. Maybe the above link helps, i'll ask him otherwise.
In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).
What forms of interprocess communication are available between the metro app and the desktop app?
Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:
According to Martyn Lovell, there isn't any deliberate mechanism for
that, and some that could be used for it are intentionally restricted.
Named pipes aren't there, for example, nor are memory mapped files.
There are sockets (including server sockets), but when connecting to
localhost, you can only connect to the same app. You could use normal
files in one of the shared "known folders" (Documents, Pictures etc),
but that is a fairly crude hack that necessitates polling and is
visible to the user. -- Pavel Minaev commenting on this issue
So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.
Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).
I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.
This post describes what functionality is supported.
Sample of my WCF server that Metro client can consume is here.
Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.
And thank you for you question. I was good starting point for me :)
There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.
Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:
Brokered Windows Runtime Components for side-loaded Windows Store apps
To quote:
Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.
Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.
There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.
I have no idea if this is possible, but it might be interesting to check out.
Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.
Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements
Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.
... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.
If you think that you can make an additional manual cmd operation,
you can try :
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.
I tried it: it works, even after package updating.
As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-
It is possible to communicate on the same machine from Metro app to desktop app using local service.
I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.
Sample here
By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.
The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering":
User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom:
"Download our PC browser powerpack and browse your entire PC, for FREE"
User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.
Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.
Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app
I have a WPF 4.0 Application which will require stopping and starting our Windows Service, Application is Called Data Service Monitor. Rest of the things this Data Service Monitor App does do not require Elevated UAC permissions.
So Now I am thinking of creating a Windows Application with No Forms or UI, just to Start or Stop a Windows Service. Thinking of Embedding Manifest for Vista/ Win 7 for UAC prompt. Calling it ServiceController.exe and WPF app will call this ServiceController.exe to Start or Stop Windows Service and that's the only time users will be prompted to Elevate
So here are the two questions:
Is this a good idea? (WPF 4.0 app calling exe to start/stop service instead of giving the entire wpf app full trust) ??
Also for Installing on Clients Machines, Will this require Digital Cert or Strongly Name Assembly? (This WPF app and ServiceController.exe will be installed on XP, Vista and Win 7 machines)
Personally, I'd give the whole WPF App full trust, because to an end user, they wont know the difference between giving one of your executables UAC permission over the other. It should make things more simple for your deployment process too.
For the digital certificate, I believe that it will work with a self-signed one, but the user may receive a dialog stating that its not from a trusted certificate authority. Getting a signed cerficiate will make your application look that much more professional, and one can usually be had from GoDaddy or similar for a few hundred dollars.
Presently I am working in a Firewall project. First I downloaded a Firewall project from codeproject http://www.codeproject.com/KB/cpp/firewallpapi.aspx which was in C++. So I made a dll from that code and called it from C# project. Its working perfectly . But in Windows 7 it is not working. Can anyone give me any hint, why it is not working at windows 7.
Thanks.
Perhaps because the API has changed:
"By providing a simpler development
platform, Windows Filtering Platform
is designed to replace previous packet
filtering technologies such as
Transport Driver Interface (TDI)
filters, Network Driver Interface
Specification (NDIS) filters, and
Winsock Layered Service Providers
(LSP). Starting in Windows Server 2008
and Windows Vista, the firewall hook
and the filter hook drivers are not
available; applications that were
using these drivers should use Windows
Filtering Platform instead."
Compile it for Windows 7 (32/ 64 Bit).
Check Event Viewer for any permission denied exception internally by windows.
It is possible to require elevation (User Account Control) but the app does not have a proper manifest so the elevation window never shos up.
Try Right Click -> Run As Admin and see if it works then.
#Stuart Dunkeld I found a solution in Codeproject.
http://www.codeproject.com/KB/IP/PacketFilter.aspx