I'd like to know what the best way to keep the different users' database accesses under control is. Since I'm implementing the common scenario of making users login to the app before accessing certain pages, I thought that it would be also nice to restrict the database access to only the data each user needs to see by creating views and new users at database-level granted just certain permissions. Those database users will have the same usernames that those users have for accessing the app, and so, when users are loging in, I could access the database with the username they are providing on the application form... Is this the correct way to proceed?
Thanks!
Speaking of a web application, the common practice is rather to have a pool of connections with a unique user.
Each request uses an already open connection from this pool. This way you'll get much better performances. (connections already open, cache of the prepared statements, ...)
As for which data the users should have access to or not, this should be coded in the service layer of the application, not in the database (in the web-application culture, I would say).
Moreover, the system you describe will be a pain to maintain proper synchro between application users and database users.
Related
I'm creating the user authentication in a web application, and I want to use Identity Server for resource protection.
The sample code and documentation shows how the user logs into Identity Server after creating an account for it. That is to say, they log in with their own Identity Server account. The quickstart even provides a UI.
But I don't want users of my application to have to log in to Identity Server, an external website. I want them to only have to log in to the web application.
So how to proceed? It just doesn't seem at all clear from the documentation how you're supposed to handle this scenario, which I would have thought would be the most common.
Do I just use a pre-defined API scope and user for token validation, holding for all the website's users? That doesn't seem to be very secure given that any user of the website or anyone with the client name and secret would have a valid token. Not sure what the point is in having the security if it's that easily worked around.
Or do I interact with my Identity Server instance somehow after the user is registered in the web application, and store the new user in a database? I can't find any mention of this in the documentation . It all seems to be very muddled to be honest.
Please could anybody shed light on some of this? What is the "standard" approach here? To have the user sign in to the external Identity Server website? That seems a great way to annoy your users.
If you only have one application and you don't intend to add more applications that needs to share users, then you should look at ASP.NET Core Identity
The whole point with OpenID-Connect/IdentityServer is to delegate the managing and handling of users/passwords (authentication) to a central entity. So individual applications don't need to deal with that complexity. IdentityServer is useful when you have multiple applications or if you have more complex integration needs. It is also perfect if you need to customize it to your own needs. If you don't need the customization part you can also outsource it to someone else like Auth0 that give you an IdentityServer like experience as a service.
Problem statement
I need to make finding all the available active directory groups and their relationships in a tree and forest structure for each an every enterprise application held on an AD Domain Server easy to identify and understand by business user and technical users via an Existing IT Service Request web based application.
What I am hoping to achieve as an outcome is:
Knowledge of an API that I can connect to extract this metadata from and synchronise with the IT Service Request Application
Knowledge of what metadata AD Domain Servers are capable of providing
Knowledge of how to connect and synchronise the meta data from the IT Service Request Web based Application without compromising security
You didn't say which language you want to use. I will assume you will use one of the .NET languages, since that is by far the easiest to interact with AD.
To read the Active Directory Schema, you can use ActiveDirectorySchema.GetCurrentSchema(). That will return a ActiveDirectorySchema object that you can use to read much of the information you would want to know. There are example for how to use it here.
For your 3rd point: to read this data you have to be authenticated as a user of that domain (or a trusted domain). Authentication is already built in. When you use ActiveDirectorySchema.GetCurrentSchema(), for example, it uses the credentials of the current user to authenticate.
I have a Xamarin app that uses Easy Table and uses "Allow anonymous access", this means anybody can access my Easy Table as long as they have the URL. So to increase the security of my app, I would like to allow only my Xamarin app to access the Easy Table I created.
Can this be done by changing the Easy Table option from "Allow anonymous access" to "Authenticated"? And if this is the case should I create an account in Active Directory/Facebook/Google and have the username/password embedded in my Xamarin app such that it can authenticate first before accessing the Easy Table?
Note, I have my own user authentication based on user email address and password and it is working okay, but this is on an application level authentication only(i.e., if users provides correct email address and password, they are able to order, view history, etc.). This obviously will not prevent other apps in accessing my Easy Tables as this authentication uses the Easy Tables in the first place.
Thanks everyone!
We have a client that we have built a webapp for and we allow their members to access this webapp via sso through an ADFS server they have provided. After implementation of the webapp the client came back to us and said that we need to query a database table in order to determine if the user that logs in via sso should be allowed to access the webapp or not. We also need to now access this table to determine what type of account this user is - i.e. are they a staff administrator, paying member or a free member
I have done several SAML/ADFS integrations but never configured ADFS myself. I am finding it hard to figure out exactly what is best practice here. I would have thought that the best practice would have been for their ADFS server to have complete control over access to the webapp and restrict based on some sort of grouping of their users. I would also expect that key attributes about the user such as TYPE come back in the response upon successful login. I am worried if we implement things the way they want we are not going to end up with a robust solution at all.
I am really looking for some advice on what is best practice and some information so I can reply with a punch because I feel their IT team who is demanding we do things in a particular way are largely attempting to avoid implementing something that they are responsible for.
Thanks for your time and advice!
ADFS is claims based and the best practice is to restrict access based on an AD security group (in ADFS terms a role) which is passed in the token as a claim.
I have inherited an application that has fairly well obfuscated, but still hard coded database password inside. The connection with that database is made using a certain database user and this password. The application users are authenticated against a user table in this database. Changing this behavior is outside the scope of my responsibility. Now the customer wants to regain the power over this database user password. He wants to change it himself. How do I go about it? I have few ideas but I would like to know whats is the best way to provide that password securely to my application?