I was wondering how an app(created with the 3 pieces shown in diagram link below) should be setup in terms of database sharing/isolation. The Web API would have authorization requirements and the identity server obviously just does authentication.
I feel like Diagram 1 would be optimal but I am not sure of the drawbacks that could be faced in the future from that kind of setup, or if it is even a proper way to use an identity server in terms of sharing a database with the application.
The issue I am finding in Diagram 2 is that the App database does not have a reference to the identity users tables, so relational data would be weird or I would have to keep a synced user reference table.
If the identity server database should be isolated from the application database, should the application database store the users full gamut of information and the identity server database just have a small reference to the users such as username/login and other authorization columns? And how would they be kept in-sync?
Related
We are using Advantage Database Server (ADS) to store data that is being used by some dashboard components in an ASP.NET 4.5 Web Form application. My connection string is set up to connect to my ADS DB in order to generate the dashboard visualizations, and it works great. However, when trying to use the built in forms for authentication and authorization, I don't know how to get the data to store in ADS.
Normally it would create a localDb SQL-like database, and store the .mdf files in the App_Data folder. However, I am not using this default connection, but am instead connecting to my ADS DB. Is there a way to utilize the Identity functions, but use ADS to store the user data?
In short, I discovered the answer is "no." MySQL (and also MariaDB) can be used to store the Identity user and role tables, but not ADS.
I have made a database and now I am trying to make a front-end application using oracle apex 4(default with oracle-xe 11g). I have included the following table for user credentials in my database.
Manager(managerid{PK},name,username,password)
I know I can create many end-user accounts from the apex for an application. But, users of application will be managers only and I have a table for them in database so it would be illogical to create separate accounts and information when I have them already in database.
My question is, how can I link the authorization of front-end application with the above table?
Regards
Create custom authentication scheme and authorize
how to refer following http://allthingsoracle.com/custom-authentication-in-apex/
and http://oraclecafe.com/2013/04/11/apex-custom-authentication-scheme/
I'm building an asp.net application that will later be ported to azure.
For the moment, I have all the business tables in one database and a separate database that I use for membership; it's basically the default database that the login control generates.
In the business database, I have a table that contains user profile data and one field is TheUserID (which is an int) and another field that's called TheUserMembership (a string), which will contain the user ID that's generated by the asp.net user management tool.
Once the user logs in, I store TheUserID in the session and the whole app works with the int as the identifier.
Is this a good way to do it? Will this port to azure?
You should be using: http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
And then yes it will port to Azure and SQL Azure.
Things to watch out for with Azure
Local storage (disk storage). Since you have multiple instances, local storage doesn't work as you will never be able to tell which instance it is on.
Session state must be out of proc, for the same reason as above.
There are many other little things here or there about Azure but those would be the 2 biggest to watch out for when moving across.
the user id is a GUID and it you can find the on the users table, you should not store user id into session since cookie can be stolen. for azure one principal requirement is that all tables have a primary key
I am currently working on converting a Windows Desktop application to a Web Site/Application. The data structure for the entire application is stored in SQL Server databases. Each database represents a different "library". One customer can have many different "libraries" (databases), and I'm contemplating placing many customer installations on the same web server.
This will be an internet site, so I'm strongly considering using Microsoft's supplied user account management for site access. I'm thinking that I would then provide administrator-level access that would allow a user to be assigned privileges on a particular database. (i.e., by default, creating a user account through the Microsoft mechanisms wouldn't give any real functionality.)
User access would have the following generic levels:
1. Read access (without this, the user shouldn't even know the library exists)
2. Insert access (user can add records to the system)
3. Edit access (user can alter the details of a record)
4. Delete access (what do you think this does :)?)
5. Admin access (user can modify other users' attributes)
I'm considering a model where there is a single account in the website that handles all SQL Server interactions. Thus, all of the code to handle allowing/denying access levels 1 through 5 above would be handled by code in my website pages, rather than by SQL Server's user account management.
I'm thinking that I would have one, central database that would contain all user names and to which libraries their account has (at least) read access (level 1 access from above). Then, levels 2 through 5 would be stored in each database for that user and that database.
Two questions occur to me:
Is this approach reasonable? Am I missing another way to do what I want (like, using SQL Server's user management tools) that is safer?
If I were going to enact this method, how would I create the "SuperUser" account on the website? I'm assuming it would be some sort of "NETWORK SERVICE" or "LOCAL SERVICE" account, but I'm still a little bit hazy about which account does what in ASP.NET.
Thanks!
Why cant you use ASP.Net Login authentication using Roles and Membership.. I think this should help you..
I'm working on an web application using ASP.NET 4.0, C#, and IIS7. The web application is a content management system that defines multiple user roles, such as editor and administrator. These users and roles are managed by the asp.net membership framework, and the associated database tables are integrated into the web app's database using aspnet_regsql. Finally, the web app is running under the ApplicationPoolIdentity. Thus, the web app runs under the virtual account "IIS AppPool\" which it does not share with any other application.
The site is designed such that user accounts are handed out by the administrator (there is no public sign-up page), although this detail may be irrelevant. In any case, the administrator should have the power to create and delete users and edit any of the content on the site. Editors, on the other hand, should be capable of editing only assigned sections of the site. Finally, anonymous visitors to the site should only be capable of viewing the content, with no option to edit.
The question is: Would it be insecure to just give read and write access in the SQL Server database to the IIS AppPool\ virtual account and give functionality to different user roles in the underlying business logic for the web application?
I wouldn't think so, but due to the necessity of the integrity of the data, I thought it might be a good idea to seek the opinion of another developer.
If (and only if) this does pose an unforeseen security risk, would it be a better idea to use impersonation, store multiple connection strings in the web.config file with SQL authentication, or track user privileges in the database itself?
The question is: Would it be insecure
to just give read and write access in
the MSSQL database to the IIS AppPool\
virtual account and give functionality
to different user roles in the
underlying business logic for the web
application?
This is how it's usually done, and for most business cases this is enough. There are insecurities in every application so you have to do the best you can to avoid buffer overflows, script injections and SQL injections, scrub your input, etc.
If (and only if) this does pose an
unforeseen security risk, would it be
a better idea to use impersonation,
store multiple connection strings in
the web.config file with SQL
authentication, or track user
privileges in the database itself?
Using impersonation is not uncommon, and very easy if you're using Windows Authentication. It's an administration headache, since users have to be added via database security in addition to the application database. Multiple connection strings is probably the least extensible and favorable of the approaches, not to mention it would hurt performance on a busy site.