I am building a REST-API that talks to an Azure SQL database using .NET core 2.2 and C#. The API runs as a webapp on Azure. The user-access rights are managed by the database itself.
My API requires the users expects users to have a Microsoft account and to be registered in Azure Active Directory and the authentication is done using Bearer tokens.
Is it possible to perform a query on the database on behalf of the user? In other words having the same access rights as if the user logged in to the database directly and performed the query himself.
I believe they need to be Azure Active Directory users if you want to grant access that way. The other option is to use SQL authentication and manage the connection string (user & password) in your web api layer.. This document from Microsoft explains the process for each: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-manage-logins
As part of a project we have integrated keycloak with our .net core application, but we have a legacy system which is a asp.net web application, It have its own login screen whenever a user logs in it should fetch the username and password and validate against Keycloak.
The approach we are trying to do is.
1.Fetch all users from Keycloak on a specific realm
2.Parse the json and find whether the specifc username and password exist in that json array.
Is this way of giving authentication is correct?
Need some suggestion!!!
Take a look at their basic authentication example...
https://github.com/keycloak/keycloak/tree/master/examples/basic-auth
As stated in the comments. Returning JSON with all of the username and passwords is NOT secure, hashed/salted/or not, it doesn't matter.
We have web application designed in VS2008. When adding some new functionality we are trying to use Web API.
In the existing system, each user from a client has access to their database. So, when a user logs in, we pull the connection string and save it in a session. Every insert, Update or select that the user performs, it uses the connection string in the session and when the user logs out, it gets cleared out.
How do I achieve this functionality if I have to use a Web API in this scenario?
Can I pass the connection string to Web API for every request?
The only other way I could think of is after every request to Web API, I have to connect to database and get the connection string based on the UserID that I have. This would add one extra step of connecting to database for every request.
Is there any other way?
Thanks in Advance
What is the login name and password for Cassandra cqlsh?
I do not see data in tables ep_profile, ep_user etc. under anonymous access.
Thanks.
In Sandbox there are not additional users created for Cassandra database. There is default user "cassandra".
You can see data using anonymous access.
By default as NoSQL DB in Sandbox used MongoDB. Check your NoSQL database configuration.
Configure if it wasn't set to use Cassandra, restart kaa-node service and connect some client to the Kaa.
Background
I have an ASP.NET web application that interacts with WCF services. The web application and the WCF services are under my control. The ASP.NET web application uses a custom implementation of the ASP.NET Membership Provider Model (with passwords stored in hashed form) to authenticate users who log in to the web application. Both the ASP.NET web application and WCF services have access to the same membership database.
Since the users will supply their password only once, and I don't want to have to store their passwords anywhere or annoy them by repeatedly asking them to resupply their password, I need an appropriate mechanism to authenticate the users with the WCF services.
Based on other questions and answers I have seen, I am considering a sort of "login session" approach, where a login session will be created in the custom membership database when the user initially logs in to the web application, with the login session identified by a GUID, and automatically expired after a period of inactivity. The login session GUID will be "remembered" by the web application for each logged in user (either stored in the Forms Authentication Ticket or in the session).
The WCF service will also provide its own login operation accepting a user name and password and returning a login session GUID as described above.
The WCF service would then accept the login session GUID for all other operations, and verify that the GUID represents a valid login session that has not expired before allowing the operation to proceed.
I have done quite a bit of background reading on this, and there is a lot of material on straightforward use of the UserName client credential type, but this would require the web application to remember the user's password, which doesn't seem like a great idea to me.
I've done some research and found material on MSDN, but this seems like a lot of effort to implement what (to me at least) seems like a pretty common usage scenario.
How to: Create a Custom Token
Question
Is the general approach of the "login session" described above reasonable?
If so, what is the best way to achieve it?
If not, can you suggest an alternative?
This is a very reasonable approach.
To do this you setup your service endpoint and configure it with your custom membership provider (You can do the same with SQL membership provider, it doesn't require a custom one).
On the web application you set up the Authenticate event of the Login control to instantiate a new service proxy and set the username/password in the ClientCredentials in the proxy.
Now when you make the call to the Service through the proxy WCF will pass these credentials through the secure channel to the service and use them for authentication.
Now you simply need to store the proxy in session and use it for future access to the service as it has the channel state and a private key.
protected void LoginControl_Authenticate(object sender, AuthenticateEventArgs e)
{
bool Authenticated = false;
try
{
MyServiceClient proxy = new MyServiceClient("MyServiceEndpoint");
proxy.ClientCredentials.UserName.UserName = LoginControl.UserName;
proxy.ClientCredentials.UserName.Password = LoginControl.Password;
//It doesn't really matter what is called or what it does because
//Membership Provider for the Service does the authentication.
string retval = proxy.login("Logging in");
//Now that channel is established the proxy needs to be kept
//since it contains the channel state which includes a private key
Session["MyServiceProxy"] = proxy;
Authenticated = true;
}
catch (Exception ex)
{
//Login Error...
}
e.Authenticated = Authenticated;
}
There are two possible solutions I can think of:
Firstly, if the WCF service is an internal service, the web application can then send the name of the user that is asking for the data with each request.
The second is that you store the user name and hash of the password (or actual password) somewhere. Either in the session state or in the user cookie (a session cookie stored in memory passed to the user over https). Then pass the user name and password to the WCF service with each request.
See my answer on Storing password in forms authentication cookie - ASP.NET and WCF calls for a solution that does not require storing passwords.
Thanks to everyone for your input. I've settled on an approach (at least for now). It's fairly simple and works well for my purposes.
Using the "UserName" clientCredentialType, and an explicit service login method that returns a security token (token generation details omitted for brevity), the service client can decide whether to pass the genuine password as the password property on the client credentials or the security token instead (obtained from the login method). If the client is a web application the security token could be stored in the forms authentication ticket, or the session, or wherever.
Using the "Custom" userNamePasswordValidationMode and a custom implementation of UserNamePasswordValidator, the validator inspects the password to determine whether it is a valid security token or a password - if it's a password the client credentials are authenticated against the user store (SQL Server database), and if it's a security token then it is checked to ensure it is valid, hasn't expired, and belongs to the user name.
I would suggest to take a look at Geneva which is aimed at solving scenarios as yours. The basic idea is to require the same security token, by mean of an HttpModule, for both the WCF services and the ASP site. The token will be release after authenticating against your membership database and may contain useful info (claims) on the user.
For an intro you may read Bustamante's article.
Microsoft has a WCF service that you can use to authenticate users with ASP.NET Membership.
The code is actually built into the framework - you just need to create a .svc file to use it.
http://msdn.microsoft.com/en-us/library/bb398990.aspx