I am trying to build one intranet application. What I am trying to do is to authenticate the user using the biometric system, fingerprints to be precise. Like in some laptops or notebooks I have seen there is
a fingerprint authentication system. The same thing I am trying to build but not for a particular person. The only difference is that the person's biometric information would be stored on LDAP server. So
that anyone who has the right access to use that particular machine can use after getting authenticated. I am trying to get the user's biometric information using an external biometric device. I have gone through few documentations on Windows Biometric Framework. And using sensor adapter and engine adapter as plug-ins I can get the user's biometric information and also get processed and can send to the server.
The only query I am having here is:
First thing first am I breaking any Microsoft's policy here by achieving this?
If not then how can I get windows system lock and unlock after
getting the response from the server whether the user is valid or not?
Has anyone ever tried this ?
Can anyone help me to get this ?
Thank you in advance.
If you're saying that you want to actually notify the built in windows login / authentication system (known as a system credential provider) that the user is authenticated then this is not supported by the official windows API. If this was supported anyone could create malware that simply notified the API that a user is authenticated / authorized, thereby essentially rendering all of windows security meaningless. So we should be grateful this is not officially supported.
Trying to implement something like that without official API support would definitely be against the terms of use. Since its not officially supported, you would have to resort to some awful hacks to get it to work, the implementation of which would almost certainly be considered either reverse engineering the kernel or hacking the kernel (or both) by Microsoft's legal team. Even if you believed they were wrong... would you really want to fight them (and their deep pockets)?
Let's also consider that if no official unlock API exists, then you would be required to use some kind of backdoor to achieve it. If such a thing even exists, then it would certainly be subject to being rendered useless by an MS update (which would nuke your app's login implementation).
Now that the fire and fury is out of the way, let me state that all is not lost, provided you are targeting a more recent version of windows.
You can implement your own biometric security system as you described. This is now known as a third party credential provider This would be a separate system, and Microsoft recommends that you require users setup a system credential provider as a fallback in case your third party credential system fails for any reason. If not, the user account would be impossible to recover. Again, they key difference from the first example is that your system is separate and distinct from the system credential provider (windows native lock screen).
I would like to stress though, that implementing a third party credential system is still far from trivial. You will want to read up extensively on the proper interfaces you will have to implement. I'd recommend starting here:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt158211%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
There is also apparently a sample located in the Windows SDK installation directory under \Samples\Security\CredentialProvider. Also, there is a nice technical reference of credential providers located here:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb648647%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
Click the link that says "Credential Provider driven Windows Logon Experience" to download the tech document.
Related
I'm trying to find a solution to handle authentication on my new application, and I like the approach of IdentityServer3. I would like to hope my requirements are met by IdentityServer3 and it's just my lack of understanding due to my newness with the technology.
My requirements are as follows, and in order of desired execution:
1) If a user requesting authentication is a local (domain) user, they should be authenticated automatically using Active Directory.
2) If a user requesting authentication is not found in Active Directory, they should be authenticated against our own User table.
3) If a user requesting authentication is in neither Authority, we may choose to grant access via Google or Facebook credentials, but that's not a Phase I requirement.
I currently have a working proof of concept using IdentityServer3 as a standalone security server pulling records from the InMemoryUsers, InMemoryClients and InMemoryScopes, and I'm fairly sure I'll be able to expand on those concepts for pulling from our own database.
This problem comes when I try to use Active Directory as the first checkpoint.
I've looked at a couple of resources in an effort to accomplish the Active Directory, but I'm getting all tripped up as I'm not seeing any concise demo that shows the AD piece of the puzzle.
TJ Robinson has a Gist of an ActiveDirectoryUserService that implements IUserService, and that looks to be the most promising, but because of my n00b status, I can't seem to figure out how to roll it into the scheme.
I would really appreciate any suggestions, and, perhaps, links to examples of how to do AD authentication first with a fallback to local authentication.
Thanks in advance,
Ric
In regard to your first requirement...
I believe you should examine the Windows Authentication Service. This is essentially a mini security-token-service that can work as an external identity provider to IdentityServer to provide Windows Authentication (over the WS-Fed protocol).
If you follow that link to the GitHub page, you will find two links to samples that can you get started with this component. One sample has both Identity Server and the Windows Authentication Service hosted separately and the other sample has them hosted together.
A separate option could be to use ADFS (if you have one) as an external identity provider.
Those samples include a custom user service (ExternalRegistrationUserService) that shows those windows users being mapped to an in-memory collection of users (in Identity Server). Your requirements will obviously demand a different implementation of that user service, but I hope this might help get your started with the Windows Auth part.
When I went through this exercise recently, I found a lot of good information in the closed IdentityServer3 issues (for windows auth). Lots of good info on Stack Overflow as well; good luck!
My organization has a Win32 application that is written in the "fat client" style. I am writing a C# Client / Server solution that will replace this Win32 application. I am using ASP.NET MVC for the server and the client is a WPF application. I did my own custom implementation of the OAuth 2 spec. I am planning on creating a Restful API, and I want for not only my client to use it, but also allow 3rd parties to use it as well.
Every app will have an api key issued to it including the official client, but the official client's api key should be allowed additional api scopes (permissions) that 3rd party users aren't allowed to use. It is pretty obvious how to solve this but if you consider not everyone plays nicely, you have to ask "What would stop someone from just pretending like they are the official client and using it's api key?" Communication will be encrypted, but the server is not in the cloud or anything like that where we could control it. Our customers install the servers on their own machines and they will more than likely have access to the server application's SSL cert. Once you have that you can easily write an app that would run on our customer's machine that could glean the API key and secret from the official client app and use that info to request tokens from the server as if you were the official client.
I am planning on self signing the default key that the server uses and I could try and hide it in the application, but that really is just obfuscation. Besides, I wanted to allow users to provide their own SSL certs so browser based 3rd party applications wouldn't have issues with the browsers complaining that they are trying to communicate with on a self-signed SSL channel.
Is there anything I can do? Here are my choices as I see it:
1) I can set it up so that only SSL certs provided by us can be used and we hide them on disk encrypted using a secret that is obfuscated in the application code. We then just hope no one bothers to take the time to dig through our .net assemblies to find the secret used to encrypt/decrypt the certs on disk.
2) We allow them to provide certs so that we don't need to be involved with that process at all when they want to use a signed cert (we don't want to be in the cert business). Now we can't even hide behind obfuscation so if someone wants it, then the official client's API key and secret is easily obtainable.
Neither seems very desirable to me. Option 1 makes us have to request addition funds from them and manage SSL certs when self-signed doesn't work for them and in the end if someone really wants them they can still take the time to get them. Option 2 just makes it super easy to steal the official client's secret.
Reasons to want to limit unofficial Apps:
1. Discourage clones
A. Tell people not do it. Have a lawyer send cease and desist letters to authors of popular apps (and to anyone helping distribute them). Intermittently download them and alter the client/server code so that the popular apps will break. For added discouragement, temporarily ban any users who used the popular app. Authors will mostly give up on cloning your app; temporarily banning users will kill their install base. This is not great for your reputation.
2. Prevent unauthorized behavior.
A. Any behavior allowed by the official app should be allowed by the custom app. Whatever scenario you are worried about, block it server-side so that neither app can do it.
You can try to hide credentials (code obfuscation, hidden credentials, etc.), but this is only raises the cost/difficulty. This is often enough to discourage code theft (no need to make code theft impossible; it is sufficient to make it more difficult than copying it by hand). However, users who want to use your api in unsupported ways can work around this.
The answer is simple. each instance of you app should have its own unique key effectively a user sign up. You then ban users who infringe your rules. in this case signing in with a non authorised client. should be pretty easy to detect by pushing updates more frequently than it would be cost effective to reverse engineer them. Much like punk buster or other anti cheating tech
I’m working on getting data sync happening for my Win8/WP8 app - written in XAML/C#. Periodically / or at app start up / suspend, I want to sync data files with the user’s OneDrive. To do that I need to get them to login to their Microsoft Live Account. I was looking to use Live SDK (v5.6) to do that.
Problem:
For users who have local Windows 8 accounts, the Live SDK lets me sign then in with a built-in credential prompt. This is working.
For users who have linked their Microsoft account with their Windows 8 account (and are logged in to Windows using their Microsoft account) the Live SDK lets me use single sign-on - and I have this working.
But I can’t call sign out, in order to sign in with a different Microsoft account.
1b is my problem. The built-in Windows Store app, lets users have a UX where they can use the MS account linked to their Windows account - OR - choose to use a different MS account. In effect: a ‘sign in as different user’ option. (See attached). It doesn’t look like it is technically single-sign-on in the built-in Windows store app, but that’s the UX I want - I don’t care so much for single sign-on, its a nice to have, but sign-in as a different user is a very important requirement.
What I’ve tried:
Lots of searching around. Found a bunch of people on the interwebs asking for the same thing. There are unanswered questions and even some ‘accepted’ answers on SO that don’t really work:
Sign in to multiple Microsoft account in Windows Store app
Windows Live SDK doesn't LogOut()
(incorrect answer)
Can the Windows 8 Live SDK use another Microsoft Account other than the current user? (incorrect answer)
I’ve forked the LiveSDK on Github (https://github.com/krishna-nadiminti/LiveSDK-for-Windows/commit/2cdb5408c0d8482c026cd96da6b99e4633677081) and tested it out - with and without requesting the ‘wl.signin’ scope - no good. It doesn’t have an option to change user.
Looked through the docs for WinRT - OnlineIdAuthenticator class, there is an option to always show CredentialPrompt when signing in users - but it does not allow the user to change the username if signed in via a linked account.
I looked through the built-in WinStore app’s js code and it uses some internal (native?) call to a ‘OMStub’ - which has methods to auth the user. This doesn’t seem to be part of the public JavaScript Live SDK
Question(s):
Are there Win32 / WinRT APIs that I could use to show credential prompts in a XAML app?
Can I use a WebView and auth users that way?
Should I just fall back to using the REST API and roll my own auth flow + UI for this?
How does the WinStore app do it?
Workarounds / Store certification:
For now, I’m a bit worried I only have the last option: roll my own .NET client over the Live connect REST API, and add my own UI for the credential prompt, and a user consent dialog which look exactly like the ones that the Windows Runtime provides. What will happen to store certification in that case? I can run it past WACK first - but the store app cert guidelines don’t talk about this: so unsure whether it will pass certification.
There is no mention of Microsoft account that I could find in the app certification guidelines.
The docs for Live SDK on MSDN explicitly mention that we’re not meant to create our own login UI: http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh968445.aspx
However, the store app seems to violate this - may be because it doesn’t use the Live SDK at all.
There is also a MSDN article that says when the user signs in to Windows with a Microsoft account, sign out is just not possible from inside an app:
http://msdn.microsoft.com/en-us/library/windows/apps/jj193591.aspx#adding_user-authentication_functionality_to_your_windows_store_apps and that the only way is for the user to dissociate the Windows/Microsoft account or switch to a different user account.
Again - clearly this is not the case. The store app provides users a way to use a different account.
Help please?
You might want to look into the Web Authentication Broker: http://msdn.microsoft.com/en-us/library/windows/apps/xaml/dn448945.aspx
It will invoke the actual Microsoft Account login flow but still give you the flexibility to sign out and back in as another user.
I'm currently writing an application in C# (Windows 8 Windows Store App, .Net 4.5), what would highly rely on one thing I never worked before: user management.
The application to be done has to access a Windows-based server, and parse the login information with that server, then display functions, profile information, etc., based on that user data. Right now I'm stuck at the really beginning, I have no clue how to solve a global user for the whole application (pretty much like the XBox application, it would be nice to have a small user representation on the top right corner in every screen).
About the platform: we use Windows solution for user management in the whole network (there's a Microsoft ActiveDirectory server running), supplying the information for the Exchange and SharePoint servers. What I want to do is to authenticate the user with the AD server, pull the information (full name, role, access, other user data), then using these information, first display the user profile on the top right corner (the XBox Win8 app style), and load the accessible functions (this will be based on role and other domains of the user, e.g. groups).
If anyone knew a tutorial or solution what can get me closer solving this very part of the problem, it would be great!
There are specific libraries included in the .NET Framework for handling active directory requests. Take a look here:
Generic Authentication Call to Active Directory in C#
http://support.microsoft.com/kb/316748
I’m looking for recommendations of how to authenticate user/password combination and verify group association across a number of differing operating systems. Basically I have a C# application that is working in both MS Visual Studio C# and Mono C# and I need to add an authentication mechanism to it to support Windows, Linux, and MacOSX.
For Windows I wrote a quick C# interop to use the Windows only LogonUser APIs. This is working well, but won’t work for systems other than Windows. My ultimate goals is to have the same set of code run on all platforms (Windows, Linux, and MacOSX) with as little OS dependent #ifdefing as possible.
One note – I am trying desperately to use the inherent OS user accounts. I prefer not to maintain my own user account store.
Any thoughts or recommendations on approaches, user authentication techniques, etc are welcome.
I'm not sure how authentication works on linux and mac but the first thing that comes to my mind is to implement an IAuthenticator interface and have OS specific authenticator classes. You can then switch over to the appropriate class manually via Dependecy Injection or perhaps dynamically on runtime...but somehow your app should be able to identify what OS it is currently running on.
Each system handles local authentication differently. As #Darnell mentioned, you probably would need to write an interface for your authentication, and hide the system specific backend.
If you need to have the same user accounts across multiple systems, ldap for user info, and kerberos for authentication is the only fully supported cross platform way to handle it.
Short of "kerberizing" you application, and insisting that it only run in an equivalent environment, there's no universal method of authentication. Also, LDAP is really the only portable way to query for group information.
A simpler (more portable) option might be to use a pre-shared key of some sort. This way the user would authorize only your program, by giving it a key with which to sign the messages. Checking the message against the user's corresponding key would let you know that a) the user exists locally, and b) the message is coming from a source which the user authorized. You still have the problem of no universal group lookup, but you probably need to do that on your own if you can't rely on ldap.
Note: I still have to stress the following
I would strongly recommend not using someone's password in your messaging, ever, even if this requires you to maintain your own user/password database. You would be circumventing the local security paradigm, and opening up the system to more security risks. This is even more important if the system is using kerberos/ActiveDirectory, where great lengths have been taken to make sure the user's password is never being transmitted over the wire. Using DBMS's as an example - most of them do not tie into the local user database (at least by default), and implement their own user authentication mechanisms. Look at how security works in MySQL, or PostgreSQL.