I'm interested in what strategies can be used for handling user authentication and authorization in a cross-platform distributed system. I would like to be able to mark actions in the system as belonging to a certain user and also to only allow certain users to do certain actions.
Background:
The system is currently used under Windows only, where actions initiated by a user is currently only tagged as coming from the particular machine of the user. An action basically involves using the cpu for doing some calculations and returning the result.
There is currently no authorization whatsoever being done and no authentication of users (or between computers). The system is running as a service with low privileges (using the NETWORK SERVICE account). Data is not sensitive and all users on the local network are allowed to use the system to their hearts content.
The system can be deployed in both homogeneous Windows domain setups as well as workgroups without a domain controller or with a mix of a domain together with a bunch of worker computers not belonging to the domain.
Problem
In order to add functionality to the system, say for instance collecting usage statistics per user or displaying who is making use of a computer it is necessary to keep track of individual users. In addition to this, if certain actions should only be allowed to be performed by certain users (for instance changing some settings for the system), some form of authorization is also required.
I have a good understanding of the Windows way of doing this and adding this type of functionality in a homogeneous Windows domain setup would be straightforward using the built-in authentication and authorization functionality in Windows. This also eliminates the need to assign special accounts only valid for this particular system to the system - once the user has logged in normally all authentication and authorization can be done without requiring any extra user interaction.
But what if the system should be able to run on Mac OSX? Or Linux? What if it is supposed to run in a mixed environment with some users in a Windows domain, others on OSX and some worker machines running Linux? (The actual system can be ported to all of these systems and handles cross-platform communication and so on). I have limited knowledge of the way authentication and authorization is handled on these platforms and no knowledge of how this can be achieved when interacting between platforms.
Are there any good strategies to use for cross-platform user authentication and authorization in a distributed system like this? Note the dual use of "cross-platform" here - both as in being able to compile the program for different platforms and as in being able to interact between platforms.
I've tagged the question as C++, since this is the language the system is written in, but I am willing to accept anything that can be interacted with using C++. Any ideas (including wild architectural changes) are welcome!
Update:
An example of what would be interesting to be able to achieve:
User A is logged in to machine 1, which is a Windows machine.
User A opens the administrative interface for the system, selects machine 2 (a Linux system) and adjusts a setting. The system verifies that user A in fact has sufficient privileges to be allowed to do this.
Since A already verified his identity when he/she logged in, it would be desirable to allow him/her to change this setting without having to provide additional credentials.
You chould use claims based authentication with SAML tokens, which work cross platform.
On the windows side there is a library for this: Windows Identity Foundation.
See: http://msdn.microsoft.com/en-us/security/aa570351
Related
I've been working on a personal project in C# that allows the user to execute scripts written by other users and restrict the permissions of that script. I can use .NET Code Access Security mechanisms to sandbox user scripts and make sure that they have only those permissions that the user wants to give them.
Broadly speaking, my security requirements are:
the user should be able to restrict the untrusted script's access to only certain parts of the filesystem, including forbidding all filesystem access
the user should be able to restrict the untrusted script's network connections to only certain IP addresses or hostnames, including forbidding all network connections
it is okay if the user script manages to hang or terminate the host application, but the user script must not be able to circumvent the permission restrictions (i.e. denial of service is okay, breach isn't)
I'm contemplating trying to do something similar in C++, as a sort of a personal exercise. Obviously, things are more complicated when running native code directly, even if the user scripts are written in a scripting language like Lua.
The first approach I can think of is to insert my own hooks in the scripting environments standard library functions. For example, if the scripting language is Lua, instead of exposing io.open normally, I would have to expose a wrapper that checked the arguments against the script's permissions before passing them to the original implementation.
My concern with this approach is that it drastically increases the amount of my own code that is in charge of security and, therefore, a potential security vulnerability that I wrote myself. In other words, when working with .NET CAS, I can trust that Microsoft did its job well in the sandboxing code, as opposed to having to trust my own sandboxing code.
Are there any alternatives I'm unaware of?
I am writing a C++ application with a postgresql 9.2 database backend. It is an accounting software. It is a muti user application with privilege separation features.
I need help in implementing the user account system. The privileges for users need not be mutually exclusive. Should I implement it at the application level, or at the database level?
The company is not very large at present. Assume about 15-20 offices with an average of 10 program users per office.
Can I make use of the roles in postgres to implement this? Will it become too tedious, unmanageable or are there some flaws in such an approach?
If I go via the application route, how do I store the set of privileges a user has? Will a binary string suffice? What if there are additional privileges later, how can I incorporate them? What do I need to do to ensure that there are no security issues? And in such an approach I am assuming the application connects with the privileges required for the most privileged user.
Some combination of the two methods? Or something entirely different?
All suggestions and arguments are welcome.
Never provide authorization from a client application, which is run on uncontrolled environment. And every device, that a user has physical access to, is an uncontrolled environment. This is security through obscurity — a user can simply use a debugger to get a database access credentials from client program memory and just use psql to do anything.
Use roles.
When I was developing an C++/PostgreSQL desktop application I've chosen to disallow all users access to modify all tables and I've created an API using Pl/PgSQL functions with VOLATILE SECURITY DEFINER options. But I think it wasn't a best approach, as it's not natural and error prone to use for example:
select add_person(?,?,?,?,?,?,?,?,?,?,?,?);
I think a better way would be to allow modifications to tables which a user needs to modify and, when needed, enforce authorization using BEFORE triggers, which would throw an error when current_user does not belong to a proper role.
But remember to use set search_path=... option in all functions that have anything to do with security.
If you want to authorize read-only access to some tables then it gets even more complicated. Either you'd need to disable select privilege for these tables and create API using security definer functions for accessing all data. This would be a monster size API, extremely ugly and extremely fragile. Or you'd need to disable select privilege for these tables and create views for them using create view with (security_barrier). Also not pretty.
I am working on a system that splits users by organization. Each user belongs to an organization. Each organization stores its data in its own database which resides on a database server machine. A db server may manage databases for 1 or more organizations.
The existing (legacy) system assumes there is only one organization, however I want to 'scale' the application by running an 'instance' of it (tied to one organization), and run several instances on the server machine (i.e. run multiple instances of the 'single organization' application - one instance for each organization).
I will provide a RESTful API for each instance that is running on the server, so that a thin client can be used to access the services provided by the instance running on the server machine.
Here is a simple schematic that demonstrates the relationships:
Server 1 -> N database (each
organization has one database)
organization 1 -> N users
My question relates to how to 'direct' RESTful requests from a client, to the appropriate instance that is handling requests from users for that organization.
More specifically, when I receive a RESTful request, it will be from a user (who belongs to an organization), how (or indeed, what is the best way) to 'route' the request to the appropriate application instance running on the server?
From what I can gather, this is essentially a sharding problem. Regardless of how you split the instances at a hardware level (using VMs, multiple servers, all on one powerful server, etc), you need a central registry and brokering layer in your overall architecture that maps given users to the correct destination instance per request.
There are many ways to implement this of course, so just choose one that you know and is fast, and will scale, as all requests will come through it. I would suggest a lightweight stateless web application backed by a simple read only database that does the appropriate client identifier -> instance mapping, which you would load into memory/cache. To add flexibility on hardware and instance location, use (assuming Java) JNDI to store the hardware/port/etc information for each instance, and in your identifier mapping map the client identifier to the appropriate JNDI lookup key.
Letting the public API only specify the user sounds a little fragile to me. I would change the public API so that requests specify organization as well as user, and then have something trivial server-side that maps organizations to instances (eg. organization foo -> instance listening on port 7331).
That is a very tough question indeed; simply because there are many possible answers, and which one is the best can only be determined by you and your environment.
I would write an apache module in C++ to do that. Using this book, I managed to start writing very efficient modules.
To be able to give you more solutions (maybe just setting up a Squid proxy?), you'll need to specify how you will be able to determine to which server you need to redirect the client. If you can do it by IPs, though a GET param, though a POST XML param (like SOAP). Etc.
As the other answer says there are many ways to approach this issue. Lets assume that you DON'T have access to legacy software source code, which means you cannot modify it to listen on different ports for different instances.
Writing Apache module seems VERY extreme to solve this issue (and as someone who actually just finished writing a production apache module, I suggest avoiding it unless you are making serious money).
The approach can be as esoteric as you like. For instance if your legacy software runs on normal Intel architecture and you have the hardware capacity there are VM solutions, where you should be able to create a thin virtual machine, one running a single instance of the software and a multiplexer to tie them all.
If on the other hand you are running something like HPUX well :-) there are other approaches. How about you give a bit more detail?
Ahmed.
I'm fleshing out an idea for a web service that will only allow requests from desktop applications (and desktop applications only) that have been registered with it. I can't really use a "secret key" for authentication because it would be really easy to discover and the applications that use the API would be deployed to many different machines that aren't controlled by the account holder.
How can I uniquely identify an application in a cross-platform way that doesn't make it incredibly easy for anyone to impersonate it?
You can't. As long as you put information in an uncontrolled place, you have to assume that information will be disseminated. Encryption doesn't really apply, because the only encryption-based approaches involve keeping a key on the client side.
The only real solution is to put the value of the service in the service itself, and make the desktop client be a low-value way to access that service. MMORPGs do this: you can download the games for free, but you need to sign up to play. The value is in the service, and the ability to connect to the service is controlled by the service (it authenticates players when they first connect).
Or, you just make it too much of a pain to break the security. For example, by putting a credential check at the start and end of every single method. And, because eventually someone will create a binary that patches out all of those checks, loading pieces of the application from the server. With credentials and timestamp checks in place, and using a different memory layout for each download.
You comment proposes a much simpler scenario. Companies have a much stronger incentive to protect access to the service, and there will be legal agreements in effect regarding your liability if they fail to protect access.
The simplest approach is what Amazon does: provide a secret key, and require all clients to encrypt with that secret key. Yes, rogue employees within those companies can walk away with the secret. So you give the company the option (or maybe require them) to change the key on a regular basis. Perhaps daily.
You can enhance that with an IP check on all accesses: each customer will provide you with a set of valid IP addresses. If someone walks out with the desktop software, they still can't use it.
Or, you can require that your service be proxied by the company. This is particularly useful if the service is only accessed from inside the corporate firewall.
Encrypt it (the secret key), hard-code it, and then obfuscate the program. Use HTTPS for the web-service, so that it is not caught by network sniffers.
Generate the key using hardware speciffic IDs - processor ID, MAC Address, etc. Think of a deterministic GUID.
You can then encrypt it and send it over the wire.
I've written a small service (plain Win32) and I'd like to know if it's possible to run multiple instances of it when multiple users are logged on.
Basically, let's say we've got UserA and UserB for UserA the service would log on as "domain\UserA" and for UserB the service would log on as "domain\UserB" - this is from the same executable of course. I can change the logon dynamically using the ChangeServiceConfig() function, but it changes it system-wide it seems, while I'd like each user to have his own copy of the service running only for him.
Thank you in advance for any pointers.
Win32 services are designed to be system-wide, and start running before any user is logged in. If you want something to run on a per-user basis, it's probably better to design it as a regular application and run it from the user's Startup group.
Is it possible to perhaps have the service create child processes which then adopt the user credentials (or be started with them)? This way you're still limited to a single instance of the service, but it is able to do its per-user jobs all the same. IIRC the Windows Task Scheduler service does this.
The whole concept of a service is that it is started before any user is even logged on. so even if this was possible, you wouldn't be able to choose between userA and userB when the service starts because none of them is logged on yet.
A possible direction would be for the service to run as SYSTEM And every few minutes check if there is a user logged in, if there is- impersonate that user and do this stuff.
Yes, that sounds close (I'm answering comment from Greg, but comments are too short to fit my reply).
I don't know the list of users beforehand, but there's a GUI control application that would be used to enter username/password pairs for each user. So, userA would log on, run the application, enter his credentials and service would use that. At the same time (after userA has logged off, but the service is still running with userA's credentials) userB logs on, uses the app, and another copy of the service starts running as logged on userB. Thus, at the same time userA and userB services are running.
Is that possible?
You are probably looking to Impersonate the users. Check out some references I found with a quick Google search here:
MSDN Article on WindowsIdentity.Impersonate
.Net Security Blog Article
It sounds as if you actually have two different, conflicting requirements, as to timing and identity.
Run as each logged in user
Run automatically even if no user is logged in.
No way to do this trivially, instead consider wrapping your program in a service; the program will run normally on startup for each user (either thru the startup folder or taskscheduler), and in addition create a service to run your app as a system user (or any other user you define).
Since you also need (you mention this in the comments) the app to keep running as the enduser even after he logs out, you can have the service manage this process for you.
HOWEVER this might not be the best idea, since the user is still effectively logged in. This can have numerous side effects, including security, performance (too many users logged in at once...), etc.
You could create an service application and a non-service(normal) application and make them communicate through IPC (Mapped File, Pipes, MailSolts ... you name it).
This way you solve all the troubles.
NOTE: The same application can behave differently - when started as a process and when started by a user, but in the end it is the same thing, you still have 2 applications (no matter if you got only one executable).
Running with different accounts is possible. In fact, this is common. See svchost.exe, which implements a bunch of OS services.
I just don't get how you determine which accounts. In a big company, many PCs are set up so all 100.000+ employees could use it. You don't want to run your service as the logged-in users, nor can you want to run it for all 100.000 users. So for which accounts, I have to ask?
A Windows process can only execute with the privileges of one single user at a time. This applies to services and other processes. With enough privileges it is possible to "switch" between different users by using impersonation. The most common pattern for what you are trying to do is to have one instance of a privileged service which registers to log in/log out events and creates children processes accordingly, each one of them impersonating the logged in user. The pattern will also simplify UI as each process runs on each separate user's Desktop, as if it were a regular application.
If you keep the privileged service's code as simple as possible this pattern has the added benefit that you are minimizing the attack surface of your code. If a user finds a security problem on the "running as user" side of your service it is a non-issue, while security problems in the privileged services could lead to privilege escalation. In fact, before Vista privileged services implementing a Windows message processing loop are vulnerable to a type of attack called Shatter attacks, which you should be aware of given what you are trying to do.
You want this running all the time, so you want a service.
You want something tracking each user, so you want an application which runs in the user session and communicates with the service (using named pipes or DCOM or whatever fits your requirements).
You don't need multiple instances of your service. From the description of your problem it looks like what you need is one service that can impersonate users and execute jobs on their behalf.
You can do this by implementing a COM object hosted in a service. Your client application (that the end user runs) will call CoCreateInstanceEx on your CLSID. This would cause new instance of your COM object to be created in your service. Then the application can use a method on one of your interfaces to pass the collected user credentials to the COM object (though I'd be wary of collecting credentials and instead see if I can pass the user token instead). The COM object which is running in the context of the service can then call LogonUser() to log on the user and impersonate it, so it can do whatever on her behalf (like finding the user local appdata folder :-)). Other answers havve good links to impersonating users using credentials or token.
If you feel comfortable with COM, I'd suggest you create your objects as multithreaded (living in the MTA), so that their execution is not serialized by COM. If not, the default single threaded model would be good enough for you.
The Visual Studio ATL wizard can generate the skeleton of a COM object living in a service. You can also read about implementing Windows Service with ATL here: http://msdn.microsoft.com/en-us/library/74y2334x(VS.80).aspx
If you don't know COM at all, you can use other communication channels to pass the credentials to your service.
In any case, once your service gets the credentials, all the work on behalf of the user will have to be executed on a background thread, so as to not block the application running as the user.