As a part of database security I have different access for every user(same as schema in Oracle). Now I want to add these users as Oracle Application Express(Apex) users.
When I try to create new users, APEX does not provide me the ability to have database users as APEX users itself.
Essentially I have three users - STUDENT,TEACHER AND UNIVERSITY.
UNIVERSITY has two table - STUDENT_INFO and TEACHER_INFO
STUDENT DB User is not allowed to view info of TEACHER_INFO and similarly TEACHER DB User is not allowed to view info of STUDENT_INFO.
I wanted to show this information through APEX rather than sqlplus. hence I need STUDENT User to login into the APEX and try to access UNIVERSITY.TEACHER_INFO and UNIVERSITY.STUDENT_INFO to show the difference. How can I add these users as APEX Users if I already have admin privileges to APEX.
First of, APEX users are not database users. Apex users are pseudo users that have schema grants by the Apex administration area.
I am assuming here that you are not trying to create an authentication scheme in Apex, totally different subject.
If you create a workspace in Apex that has access to all 3 schemas (which is no problem). You create a single admin (again pseudo apex user) with full control.
That admin can create other users inside the adminstration->users interface. There he can grant access to all, none or subset of the schemas. Define them as application users, developers (which you want, so they can log into apex) or admins (do not want)
I took this from the internet. Notice the accessible schemas field., There you define it.
As I understand, you want to get access to tables in SQL Workshop?
First you need to know, that oracle database users and oracle APEX users are different things. After creating APEX users you need to go to Administration and find there menu for managing workspaces. I have no APEX now besides account at apex.oracle.com (administration functions there restricted), and don't remember exact names of menus. You need to give that users access to workspace (if necessary), and after that define, which database SCHEMAs this workspace can use (it is also in workspace management section). It can use one SCHEMA by default and other SCHEMAs can be added later. After adding SHEMAs UNIVERSITY and STUDENT you will get access to their objects in SQL Workshop.
Link to documentation: https://docs.oracle.com/cd/B28359_01/appdev.111/b32258/adm_wrkspc.htm#BABDEBHA
Related
can anyone explain the complete process to create a snowflake organization account and the way to attach/detach account from it? I looked into the snowflake console as well as in documentation but have not gotten clarity
You should submit a ticket to Snowflake Support to enable organization on one of your accounts. This will create the ORGADMIN role in the account. Then you can grant this role to one of your users. The user which has the ORGADMIN role can access the Organization page. From the organization page, you can see your existing accounts, and create new accounts. When you create a new account, it will be in your organization automatically.
If you have an account which you can't see on the organization page, that means the account was created in another organization. In this case, you need to submit a ticket to Snowflake Support and ask them to move your account to your organization.
Normally, it's expected that each customer should have one organization, but if you have multiple organizations, you can also ask Snowflake Support to move your account from one organization to antother (that's how you would detach). If you want to drop an account, you should also contact Snowflake Support, it can't be done through the organization page.
I have been searching for articles and SQL script examples that would demonstrate how to securely and conveniently solve one of the most common scenarios - connecting from a .Net Core Entity Framework based web application to an SQL database.
But somehow I could not find any coherent step-by-step guide from a reputable source.
Let's assume the following:
I cannot use integrated Windows auth in the connection string and must use username and password based auth (because hosting on a Linux server and the DB is on a different Windows server)
the web service will need your usual minimum set of permissions - connect to the database, read data, write data, delete data, execute stored procedures
While reading many tutorials, I find there are multiple ways to manage the connection permissions. To avoid this question being too broad, I'll list my current choices as I understand them (please correct me if I'm missing something).
Users and logins:
create a login and a user for the database
create a database-only user without a login (not sure if this is applicable to a web app and connection string, but still it's a feature that I've seen being used)
Assigning permissions:
assign the user to some fixed SQL role (db_datareader, db_datawriter AND also will have to grant EXECUTE permission)
grant all fixed permissions
create a custom role (let's say, db_web_apps) with required permissions
Which choices are better (more secure and easier to manage in general) and recommended by SQL DBAs?
I think every database administrator should have a template script handy for quickly adding a new user with minimum required permissions every time when developers ask for a new connection for their shiny new web app.
If you know a good, reliable tutorial or GitHub / Gist example that explains what and why is being done that way or a script that you yourself have used for years without any issues in production environments, I'll really appreciate if you could share it.
Create a role in the database and assign the required privileges to the role. Don't use the fixed database roles. Instead grant permissions directly to objects, schemas, or the entire database if necessary. Like this:
create role trusted_app_role
grant select, insert, update, delete, execute
on schema::dbo to trusted_app_role
That will grant the role full DML permissions on all the objects in the default dbo schema. So if you have any tables or procedures you don't want the app to have access to, just create them in a different schema, say, admin. This way you never have to fiddle with permissions as you add objects. The fixed database roles predate schema-based permissions, and aren't really needed any more.
For your application's identity, add Active Directory or Azure Active Directory (Azure SQL) identities to this role, or, if you can't, add SQL Users to the role.
If you are on Azure SQL, you should normally use a database user without a login. On SQL Server you can only add "contained database users" if you enable Partial Database Containment. Which you can do, but is incompatible with Change Tracking and Change Data Capture, so it's a tradeoff.
So normally for SQL Server you still create a login and map the user to the login. EG:
create login web_service_user with password = '5X+jeuAB6kmhw85R/AxAg'
create user web_service_user for login web_service_user
And then add that user to your role
alter role trusted_app_role add member web_service_user
I am working on a company project, in which it contains a data processing system and this system was previously written separately for each bank and have their own project file, and each of the project has their own database that store the user credentials for them to login using their id and password.
Now we need to merge all the projects together so that it only login via a single login page, but i am wondering how am i going to do this because the data, especially the login credentials is stored in different databases. How should I pass data from a database to another database to perform validation?
Assuming these are SQL server logins, You will probably have to build a database with an availableDB table listing the available databases. Let the user choose a database, then try to open that database using the specified credentials, kicking him/her back to the choose-a-database point in the application.
If that doesn't answer your question, we'll need a little more information: architecture, desired interface, etc.
Hope this helps.
Why Dont You Use a drop down on login form with Every bank name listed in Drop Down. After selection of bank, use if and else statements to populate selected bank database.
I'm trying to set up security for my application for users. I am not sure about my logic. Is the following possible:
I want to create 1 login for 'all users' in Active Directory. Then I want an admin (in the program self) to choose which user is in which server role (e.g. marketing, sales, ...). Then I want to give those roles permissions to the tables in the database.
Some questions about this:
Is this safe? The admin of the program has to be db owner?
Is it possible to list the users by name, instead of the login 'All users', the admin has to be able to place a user in a role after it is created in Ad.
I use the function SUSER_NAME(), will this return the current user or the groupname 'All Users'
If this isn't the right way to make security, please send me in the right direction.
Thanx!
Part of the best solution already lies in your desire to use the Active Directory to authenticate your users. Let it authorise your users as well. Marketing isn't just a database role that specifies access to your tables. It's a department of your company with file shares, mailing lists as well as a role to play in your application. Get your domain admin to make an AD group called Marketing and let them add and remove people as appropriate. Likewise for the Sales department and other departments who touch your database.
When that is done, add the MYDOMAIN\Marketing group as a login on your server and as a user in your database. It will behave more or less like the roles you've described so you can still go ahead and create the roles, add that domain group to the role and grant to the role or grant to that user directly since it identifies a group of people. This also gives you the chance to reconsider your role definitions. Are they really about Marketing people and Sales people or are they CustomerEditor, CustomerViewer, ProfitAndLossViewer roles?
User and group management is a standard function of AD administration; let them do what they do best. It probably doesn't need to feature too strongly in your solution unless you get very poor service from the domain admins, in which case, why use your AD to manage your users?
This very small change will probably free up a lot of your dev time and release you from reinventing a user management facility that already exists and is easy to use.
Good luck!
here's what i would do:
create two roles on the database, one users, one admin. then create two security groups in ad, SQL.App.Admin, SQL.App.Users (replace app with whatever your app name is). I would then assign those groups to the roles in the database. after that you can drop users and/or security groups into those two groups.
Here is the scenario. I have a SQL Server 2005 production database/server. It currently has developers and supporters who can connect to it. I need to create a security module that gives developers read-only access to all areas of the database. This means that a developer should be able to view all objects as well as scheduled activities/jobs only.
Is it possible to enable security in this way and if so can I be gently guided on how to achieve this. I am learning to be a DBA and creating snapshots of the databases are not an option.
Thank you all in advance.
There is permission to every object.
Create a stored procedure that grant each gruop the exact permission you need on the objects you need to protect.
I'm not quite sure I follow where this "security module" will be in the architecture. Anyhow, here's one possibility that secures it from the database end.
I'm going to assume you already have users created.
Create a new role (yourdb > security > roles > new database role), say "ReadOnlyDevelopers". Make the owner dbo or whatever makes sense. Do not select any schemas to be owned by the role. Populate the "Role Members" with your developers.
Next, open the properties page on your database. Go to the permissions page. Click Add... and add the new role. Under the permissions grid at the bottom, Grant SELECT to the role.
Now assuming your developers already belong to some other role, you'll need to go into the user properties and under Database Role Membership restrict them to just the new role. At this point they should be able to just read
I'm guessing that I'm missing a detail or two (the role may need to be grated a few additional rights to "see" the database, alter passwords, etc.) but I can't get to that level of detail without setting up the entire scenario. Hopefully this pushes you in the right direction.