First off, I know the best-practice is to use a single database user account in your web app to take advantage of connection pooling to keep the app nice and responsive. However, due to the REQUIREMENTS (as in no changing this under any circumstances), I must authenticate each user with his or her database account.
The context is a warehouse management application that runs on Android, but gets its data from web services that I'm probably going to write in Grails unless a suggestion here shows me a tech more suitable for my requirements. Due to the nature of the application, the users would likely only need to authenticate once or twice a day, so I was thinking I could simply persist the Connections in a HashMap keyed by the hash code of the username concatenated with the password. That should allow the application to maintain the same or similar performance level as the best practice.
Now, my issue is in using the persisted Connection objects. I know that I will not be able to use them with GORM without a significant amount of customization, so I was planning on using them with groovy.sql.Sql, which works out well because most of the business logic is in PL/SQL packages anyway.
My question is how does the groovy.sql.Sql class deal with its Connection object? Will I run into issues of Connections being closed by it, or can I safely use my HashMap to persist the Connections?
groovy.sql.Sql will not close your connection. In the class spec you can find:
If this SQL object was created with a Connection then this method
closes the connection.
So SQL class is really if you want to do things by yourself, not trusting entirely on Hibernate. Although, I think you can use Spring's UserCredentialsDataSourceAdapter for your solution. It uses ThreadLocal to set credentials for each thread, so the call to: UserCredentialsDataSourceAdapter.setCredentialsForCurrentThread(String username, String password)
would solve. There are other aproaches you could try here.
I actually just found something that future visitors to this question may find useful. While digging into the Spring Framework's documentation, I discovered that their JDBC Extensions actually implements proxy authentication (where a proxy account is used to establish the connection, but an actual account is provided for the context of SQL execution). Unfortunately, the implementation as of 8/17/2012 does not support using passwords for users over the proxy connection, so it won't be usable for me currently, but anyone finding this question should check to see if that is still the case. Here are the links:
JDBC Extensions Docs v1.0.0.RC1
JDBC Extensions Docs Base
Related
I have a Delphi-based client-server application. The server is a fairly simple application with a TRemoteDataModule. The client application connects to it via a TSocketConnection.
Everything is working fine on that front.
Is there a way to access the list of currently active connections for the TRemoteDataModule?
The reason I'm asking is because I would like to prevent users from connecting from more than one machine at a time to the same server, so I figured I would keep a list of usernames per connection and check against it whenever a new connection is attempted, or beforehand, client-side, via a a COM function.
Or should I be using some other mechanism altogether?
As an aside, is there a way to see which threading model and instancing model were used when creating the RDM? I'm not the one who created it, and I don't know where to find that.
Cheers!
Using Delphi XE5, if that makes a difference
According to this post, it's possible to decompile an iOS application.
How can I prevent an attacker from gaining access to my AWS DynamoDB database? Just having the access keys out in the open like shown on the Amazon developer guide doesn't seem like it would be very safe.
I would think that I could use keychain to store the keys, but I feel like there would be an easy way to get past this for a motivated attacker, given they have the app's assembly source code.
Currently, I connect using Amazon Cognito. All I have to use to connect are the identity ID and the role name. I don't see anything stopping an attacker from simply getting those values and connecting to the database.
For example, what stops an attacker from decompiling the Facebook iOS app code and deleting all of the users?
How can I prevent attackers from decompiling my iOS application and getting access to the database access keys, or at least prevent them from doing any major damage, such as deleting users?
Based on my admittedly limited experience, I'd say that a really motivated attacker will always be able to retrieve the credentials you use to access your database regardless of what you do to your executable. I would, however, question why you application needs to have direct access to your database in the first place.
The usual way to safeguard your serverside data is to use a web service to access it. App contacts web service with request, service contacts db, gets data, sends it back. Since the web service and the db are both hosted on your server and only the web service needs direct access to your db, there is no need to store db access info in your app. Problem solved.
It's impossible. In order for your program to do something, it must contain the instructions that allow the computer to follow to do that thing, which means anyone else can also follow those instructions to learn how to do the exact same thing.
You can use SQLCipher and use your auth's userToken and/or userId as cipher keys.
I'm currently designing a new website built on MVC and I wonder what is the right way to manage state.
The state should contain the userId and some structs of the user info, and should be kept during the whole session of the user while he's logged in (across http requests)
The important criteria:
1) Support scalability
2) Performance
The easy way is to use the Session object, but it doesn't support scalability. If different requests during the session go through different IIS servers, the session won't be kept. Although I've heard of load balancing tools which route all requests of a single session through the same machine, I'm not sure that it's a good practice to rely on it (isn't it?)
Another option that I've read about, is keeping the state data in special state servers which are running a RAM DB (like Cassandra for Linux or Redis for Windows). But it seems to me an overkill at this stage of the development.
Do you have any other suggestions?
I would like to start with something simple at the moment, but keep the design ready for a more advanced solution at the future.
Any best practice or code/design suggestions will be appreciated.
Thanks,
Edi.
(1) Use Sql Server to Store Session State
(2) Use Memcached as a Session State Provider
(3) Cook up your own solution using Caching on an external caching provider: look into using something like the ServiceStack Caching Framework. Using this, you can use Redis, Memcached, Azure or AWS to handle caching.
Next, create a KeyFactory to handle generation of keys for specific items. The item keys would include the UserId (which you would always have from FormsAuthentication UserId (assuming that you are using FormsAuthentication). Then store any Session data for the user in the cache. Using this approach you are using Caching in place of Session, and the cache can be shared across multiple servers.
Note: you can have different approaches regarding clearing out the user's data whenever they begin a new session. Potential approaches include:
Include the user's session start dateTime in the cacheKey, and auto-expire entries when they are no longer fresh
Clear out all potential entries for a user when they begin a new session
If you are using .NET 4.5 and dependent on the type and amount of information you are keeping on users you may want to look at using claims to store information about the user. In .NET 4.5 all Principals inherit from ClaimsPrincipal. ClaimsPrincipal already uses claims to store the user name, roles and other information. You can create your own service to transform claims, which will allow you to add additional information to the Principal user.
In a multi-tenant (seperate database per client) model is possible or even desireable to use either the Microsoft MembershipProvider or the SimpleMembership providers?
the original membership provider is configured from the web.config and the Simplemembershipprovider (in MVC4 template) has a method which initialises the database per application start rather than per session or request.
Is it the case that the membership/simplemembership providers are therefore tied into the application or inprinciple is it a sensible fit to change the database connection to point to the requesting clients database per request?
It's possible with my custom membership provider:
http://blog.gauffin.org/2011/09/a-more-structured-membershipprovider/
Create your custom IAccountRepository on top of the one in the SqlServer package. A lot easier than implementing your own provider.
I've seen and implemented something very similar to that, based on code from ASP.NET: Supporting Dynamic Applications.
This is not the same as what you are asking - the goal here it to use the same membership database, but with a different Application Name for each client.
I am not sure how you can set the connection string dynamically though - SqlMembershipProvider does not expose that property. You might start with Initialize, but as you've said, it doesn't run on each request. There is also the option of creating your own provider, and creating an internal SqlMembershipProvider per request.
We established that we needed to use dependancy injection to add custommembership providers per tenant request. Through thorough investigation it was apparent that we couldnt modify the connection for the membership provider and ensure it hadnt been remodified by another request prior to completion of the request. Due to its singleton design.
Cheers
Tim
I hate to re-invent the wheel so I'm looking for an existing solution to create a simple authentication system for my application. I've experimented for a while with using CardSpace or OpenID inside the application but I can't convince management that these would be working solutions.
Of course, I could just build a simple login dialog where username, domain and (hashed) password is stored inside a database table and I've done such a thing many times already. I hate this solution since I feel it's just a weak option. And I don't want to spend too much time trying to make the whole logon system as secure as possible, especially since I suspect that there should be existing solutions for this.
So, next to OpenID/OpenAuth and CardSpace, are there any other Authentication solutions that can be used from a Delphi/WIN32 application?
Right now, the application will be used by many customers. Most are single-user environments, although it's likely that some of those will start to have two to 5 users once this authentication system is added. But we want to support a customer who needs to allow about 500 different users on the same application. These are spread over about 100 offices but they all connect to the same SQL Server database. (MS Access right now, but we're making it possible for this user to use SQL Server instead.) To make matters even more interesting, the customer uses Citrix to centralize the user systems and the application has straight access to the SQL Server database. It's not an ideal setup but then again, the customer isn't really paying for this. We're just setting up a test environment. A proof-of-concept which the customer will test for us. Flaws will be solved later on. But right now I need quick solutions and one of them is a practical authentication system where I don't have to write a lot of code.
Have you considered using SQL Server authentication and not allowing authentication for those using an Access Database?
If you use the new SQL Server Native Client and SQL Server 2005 you can have passwords expire and change them from your client application. All of the tools to create and manage user accounts are built into SQL Server Management Studio. And if you decide later to support Windows Authentication you just need to modify your connection string.
We have a system where users on the network use Windows Authentication so they don't need to worry about another user name and password. For users that access the system via a VPN and non-domain joined machines they use SQL Authentication.
Here is the MSDN Page that talks about dealing with passwords programmatically in SQL Server 2005
You do need to make sure that SQL Server Native Client is installed, but that is simple compared to the rest of ADO.
I would suggest then
Delphi - since you are using Delphi :)
Open source - since you need to be able to figure out what is wrong if there is a problem, you probably want it cheap.
So, here are some solutions:
http://www.torry.net/pages.php?id=313
CoWindowsAccount v.1.0
SSecurity v.1.2.1.3
http://free-password-manager-plus.software.informer.com/1.6/
It might work for your purposes, but why not ask Windows for the current domain and user name, and use them as unique IDs. Windows has already done the authentication, and it saves the users making up new passwords or anything. I've used this to good effect. I also made it optional to include the machine name in the ID, so that the same user on different computers would also be unique.