I'm trying to connect to Azure Analysis Service databases (which isn't owned and managed by me) with Adomd client library.
I can connect to them with Power Query connector using Microsoft account, but I couldn't find the correct connection string to prompt me to login with my Microsoft account then use that credential to connect in Adomd. Using the connection string in here https://learn.microsoft.com/en-us/azure/analysis-services/analysis-services-connect
"Provider=MSOLAP;Data Source=<Azure AS instance name>;"
leads to this error
Authentication failed: User ID and Password are required when user interface is not available?
Is it doable with Adomd client?
Turn out pythonnet prevents interactive login. I makes it work by using the client library in C#.
I am using Windows Redis service (Redis 3.0.504) as my cache server, and enabled the password verification by configuring the variable "requirepass" with a password.
But when I test it, it seems that redis server stops checking password for all the clients after a successful password verification from any client, feels like a successful password verification simply unlocked the Redis server for all.
In my implementation, I am using a ServiceStack web service as a wrapper to the IRedisClient, and only expose my webservice to cache clients so that I can keep redis server for local access only due to its security vulnerability.
In the web service, I am using castle windsor for the dependency injection of an instance of PooledRedisClientManager object for the request to obtain a redis client (IRedisClient). The code is similar to the following:
In web service init:
container.Register<IRedisClientsManager>(c => new PooledRedisClientManager("password#localhost:6379"));
In service controller, to obtain a redis client as below:
public MyServiceResponse Any(MyServiceRequest request)
{
...
var redisClientsManager = HostContext.Resolve<IRedisClientsManager>();
using (IRedisClient redisClient = redisClientsManager.GetClient())
{
redisClient.Password = request.Password;
...
}
...
}
I am not sure whether Redis is incapable to enforce the password verification, or there is a flaw or an issue in my solution/implementation.
Thanks!
Redis enforces its password with the AUTH command where once validated, it allows access to all Redis operations for the connection from that point on.
In ServiceStack.Redis the password should be specified on the Connection String where it will ensure every new connection to Redis is authenticated with the password specified. You wont need to be concerned with specifying the password in your App's logic as it's automatically provided for each new Redis connection created in the pool.
Note: the recommended API for accessing Redis in ServiceStack Services is to use the base.Redis property, e.g:
public object Any(MyServiceRequest request)
{
...
var value = Redis.GetValue(key);
}
I developed a webapplication Example1:7575 which uses FBA. Now, I deployed these WSP's to a new server Production:2525 to get the same functionality of my previous server's webapplication. However, I was not able to fetch the data from sql server and I'm getting the following error: A Membership Provider has not been configured correctly. Check the web.config setttings for this web application.
Actually, I have manually entered the same membership and role providers of my previous server's central admin, security service token & web application's web.config entries to this new web.configs and matched them.
Can someone help me with where I might be doing wrong. Any help would be greatly appreciated.
If you can't fetch data from SQL Server there's probably an issue with permissions to the database. Check the database connection string that FBA is using. It likely uses Windows authentication to connect - in which case it will be connecting as the user assigned to the app pool for the web application and the secure token service. Check that the configured app pool identities have permissions to access the sql server databases.
I need to create an application for a company and they would like to have people login to the application to have different permissions to perform different tasks.
My initial idea was to create a MySQL database, hardcode the credentials into the application and have the application connect to the MySQL database. The MySQL database would then have a table called "users" which would store usernames, passwords and permissions. The application would then query the server and perform the authentication.
The biggest problem with this is having the MySQL credentials hard coded into the application. If the application gets into the wrong hands, they could do lots of damage to the MySQL database if they snoop around to find the credentials and start dropping tables.
So I thought of developing a server that acts as an interface for the MySQL Database. For example, the client application would connect to the Server via TCP, and the server connects to a MySQL database. That way the MySQL credentials are never exposed to end-users. However, this means I have to develop a server application which a) will be harder to maintain and deploy for my customer (as opposed to just setting up a MySQL Server) and b)Has potential to introduce more bugs since I have an additional system I need to make (which relates back to point a for deploying bug fixes, etc)
So I was thinking instead of having a table of users in the database and having the application connect directly to the MySQL server with hardcoded credentials, the end-user would be given actual MySQL user credentials in which they would enter into the application to connect to the MySQL server. This means if someone gets their hands on the application, they can't do any damage to the MySQL database, but there still remains the risk of an end-user giving their credentials to the wrong person.
What are the best ways to have a desktop application connect to a MySQL database? Are there any other solutions other than the 3 I have thought of, or do you have any thoughts on my solutions?
As #Perception noted. Your best bet here is to implement a web service in front of MySQL. You don't want unknown numbers of clients from unknown IP addresses all having access to your database.
It would be really easy to DOS attack you by tying up MySQL connections. Not to mention that you would very severely limit your ability to scale your backend service to meet the demands of an increased client base without having a web service in between.
The web service could also offer you the ability to control user authentication and authorization in any number of ways (user/pass combination, token-based access, OAuth access, etc.).
Where I work there are two practices I have seen:
Each entity (person, thing, or business (depending on level of granularity needed) accessing the database) has their very own credentials. This was used on an MSSQL and on a Rocket Universe database. This is mostly the retail and legacy software.
We host the application ourselves and use a separate authentication system for users. The database credentials are stored on our server where the application is hosted. The client knows nothing of the backing database. These are usually web apps and web services.
Something you could do that we have done is that many of our applications actually talk through a RESTful service that emulates the database in a way. The application itself has no access to the database. I would read the wikipedia article on restful services for more information. Our authentication is done using Nonce encoded HMAC requests where each user is given their very own key tied to their credentials.
Wrapping the database in a web service gives you a few possible advantages:
If you decide to change your database structure while keeping the same information, you might not even need to update the client applications, just the service.
Credentials never leave the server, your credentials remain safe so long as nobody gains access to your server. Security in general is increased.
If you do your service cleverly enough, you could even transfer much of the internal logic that would normally be client side onto the server, making updates and bugfixes virtually seamless to the client.
The disadvantages that I see:
It is one more thing to maintain
Your application is vulnerable to denial of service attacks, but since it is a database that's a possible problem anyway
If the server goes down, all the client applications go down, but again, still a problem anyway.
RESTful architecture: http://en.wikipedia.org/wiki/Representational_state_transfer
HMAC: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code
Our HMAC system works like so:
User logs in using username and password to their local application.
The local application communicates to our authentication service and gets a "Session Key" and shared secret for that username and password.
Using the Session Key (which expires in a short period of time), the application creates an API Key (which lasts a long time) and stores it to the computer. The session key could be used instead of an API Key if the user is required to log in each time. We mainly did it this way for convenience for some programs. If the computer is not secure, the Session Key should be used only and no API key is stored on the local machine. Each time the user logs in, they get a new Session Key.
Each request to the database service is accompanied by a HMAC-signed nonce which the application gets from the authorization service based on the API key. After getting the nonce, the application signs it using the shared secret. These signed requests can only be used once since the web service (which the user could know nothing about) authenticates the request. Once the signed nonce has been authenticated server-side by seeing if hashing the nonce with that particular API/Session Key's shared secret results in the same digest, the nonce is marked expired and the request is granted.
The above is vulnerable to man-in-the-middle attacks if HTTPS is not used, so often people make a message based on the nonce and the URL being requested along with a timestamp and compute the HMAC on that. The server then recreates the message based on the URL, checks to see if the timestamp is within some bounds (+/- 4mins or something), and then authorizes the user based on that information.
To further granulate operations, we also have a role system which checks to see if the user who owns the Session/API Key has been given permission to request the thing that they were requesting. If they have the appropriate role, the request is granted.
Summary: Credentials are done user-by-user, the end user has no knowledge of the database, a web service wraps the database in a RESTful API, and a role based system is used to make permissions granular.
This is just a suggestion and I am not saying this is the best or only way to do this. This just happens to be how we have ended up doing it where I work.
Let's look at two ways of dealing with database:
Client directly connects database, and manipulate database
Server connects to database and provide interface for client to use
Considering your use case:
valid valid serial number or to store/read information about certain user
it can be designed in the following way to provide security. (I'm no expert in this)
Client directly connects database, and manipulate database
You don't have to use your admin to visit database, instead you create a user for client only, and limit user's access privilege to only viewing (certain data). And you can enforce security policy at database by changing privilege for this user.
you can consult MySQL :: MySQL 5.1 Reference Manual :: 6 Security for more info.
6.2 The MySQL Access Privilege System
6.3 MySQL User Account Management
Server connects to database and provide interface for client to use
You can use HTTP and provide interface to client to use. And only the backend connects to the database.
Something like RESTful API, there are many easy to use framework that provides authentication and authorization.
I don't think it's good idea to let client have direct access to database in your case. So if possible, the second option is better.
Also note that password based authentication is not ideal.
I want to make a connection between an external LDAP server (e.g. Active Directory server) and my webservice. I want to make sure that a certain group of users from the LDAP server stays in sync with my webservice, e.g. when a user gets deleted from the LDAP server, the LDAP server should push this change to my webservice so the user can be deleted from my webservice as well.
Any suggestions on how to achieve this?
The comments to your question indicate that you should retrieve data as required from the directory server instead of trying to maintain synchronization, with which I agree.
If synchronization is still your desire, you may be able to use persistent search, which notifies the connected client of changes in the database according to search parameters. Not all server support this mechanism, however.
see also
Persistent search in Java
LDAP: Persistent search