I've already created a Welcome page where a user chooses amongst 3 user types (buttons). Each button takes the user to their own login forms. After they login they are each taken to their own switchboard.
The problem is they can still see the options on the left. I "unchecked" the option in options menu, but they can just check those if they wanted to, to see them.
I want some users to be locked out from accessing those navigation options permanently because there's sensitive information in some of the tables.
Is there any way to do that?
If you want to accomplish your objective using just Access then you'll need to store the tables in an .mdb file and configure it to use user-level security. However, that approach has at least two significant disadvantages:
User-level security can be a nuisance to set up and maintain, and
That security model (encrypted .mdb files and associated .mdw "workgroup" files) is deprecated.
If you're serious about your security requirements then you'd be better off using something like Microsoft SQL Server (perhaps the Express Edition) for your back-end data store.
Related
Let me preface this with the fact that I don't know much about VBA. I have created a database that will be split and the front end will be distributed to 14 different project managers. The database is intended to allow users to enter bi-weekly updates to their projects. I hope to get some guidance on creating usernames and passwords so that PMs can only access their project data.
I don't mind creating and issuing usernames and passwords to each user, but I am trying to avoid creating 14 copies of the database. That would make providing updated databases a nightmare.
Hopefully this isn't too basic of a question for this group.
yes, you can control users access, you need to create a user table in your backend database that will hold their firstname, surname, password, and any other user specific data that you might need, e.g. department, access level, etc.
In your front end, you need a login form and you make that the Display Form for your fe (set in the access options menu). You check the username and password entered matches what is held in your database, and if it's correct, you load the appropriate form, usually a main menu, and show them the appropriate data based on the login they used. You may need to hold the login they used in a TempVar, so you can access it from any form, report, query etc in your frontend.
You will need something like LASsie (Light Application Security) or program a similar solution yourself.
Also, you may enjoy my article Deploy and update a Microsoft Access application with one click.
(If you don't have an account, browse for the link: Read the full article.)
I'll summarize the operation to give you a background.
I've an Access database in place with forms wherein a user inputs with diverse fields. This file is hosted on a shared network for my organization. The database is split between backend and frontend.
Issue(s):
- Multiple user cannot access a single form and simultaneous entries are not allowed.
- In case, if the file is opened by mistake it will prevent to enable submissions for other users on the network.
I am not sure if this will work as I am a newbie in Access. But can we create a HTML based form which will fill the tables in Access? If yes, kindly help in creating one. If not, kindly suggest an alternative.
Sample table attributes:
Date Name Type Remark
This is the same type of setup I use at my company. We have one backend (all the tables) and a frontend (queries, forms, reports, etc). The way to allow multiple users to work with the database is to have each user run their own instance on their computer ie have them copy/paste the frontend to their local desktop. Another thing to keep in mind is that the tables must be set up with primary key and autonumber field to prevent users from accessing and editing the same record.
I have a business case where I am developing a simple search UI, I would like to link it to our SQL Server as the performance is pretty fast when I test it. My plan is to create a few linked tables and create a tidy search form for each linked table (different datasets).
UPDATE, here is a better description of my plan
I have a single user ID / Password that I want to use in each ODBC connection on 4 linked SQL tables (its considered an APP ID at my company, the PW never changes). There will be 4 forms that link to each of the tables and each user will have their own accde db with a launch file that places a copy on the users profile drive and opens it from there. This allows each user to have their own copy of the accde file and everyone to have only one "launch" file.
This search UI, will have upwards of 2000 users, who knows how many actually executing a search at any given time. Security is not a concern as it is a DB on an internal SQL Server which is managed by our IT area. The end users are all internal employees.
Will using just the one ID potentially lock out my APP ID and cause major issues?
Will MS Acess no longer be a major choke point if each user has their own accde file?
Thank you and sorry that my first version of this question was not 100% clear, thanks!
So, I figured I would circle back and post up what I did. While providing a singular app ID with a File DSN in a shared location for the Access Front end would have worked, it was ultimately not the most stable solution.
Since I am in a large corporate environment, my options were extremely limited. That said, I was able to have a read only role added to the database I manage, sourced an "Active Directory Group" that had the membership I needed (as a bonus, the membership was managed at the corporate level!) and I added the AD Group to the read only role.
I then created a File DSN using windows authentication security, placed it in a shared folder location (where I also added the same AD Group to a read only role on the folder) and emailed out a shortcut to a simple batch file launcher that copies an ACCDE database to the users profile drive.
The accde houses all the necessary search forms, logic and linked tables needed for the end user. I even build in a back door that crashes out the end users (with a warning) with a simple file rename. The front end runs surprisingly fast with the test group of 100 individuals and is rolling out to 500 next week.
Viola. Hope this helps someone trying to do something similar.
I'm trying to get some advice on how to approach a security architecture on Azure.
Background:
We are looking at building a multi-tenant app on Azure that needs to be extremely secure (personally sensitive data). The app will be accessed by standard browsers and mobile devices.
Security access types:
We have three types of users / access types...
1 - plain old user/password over https is fine, accessing both general, non private SQL plus hosted files
2 - user/pass over https, but need authentication of users via certificates that will be installed on user machines/devices. This level of user will need access to sensitive data which should be encrypted at rest both in database, and also any uploaded files.
3 - same as (2) but with the addition of some two factor authentication (we have used YubiKey for other things - might look towards a phone OTP offering as well)
Most users will only have access to their own tenant databases, however we have "account manager" type users that need access to selected tenant data, therefore we expect that they will need either a copy of one certificate per tenant they serve, or we will have to use some kind of master certificate.
Database type:
From a multi-tenant point of view it seems Azure Federated SQL is a good way to go because (a) we simply write one app with "TenentID" key in each table, and after login, set a global filter that handles the isolate for us (b) we understand that Azure federated SQL actually in the background maintains separate SQL database instances per tenant.(Ref: http://msmvps.com/blogs/nunogodinho/archive/2012/08/11/tips-amp-tricks-to-build-multi-tenant-databases-with-sql-databases.aspx)
Can anyone point to any links or give advice in relation to the approach needed to setup and manage file shares, encryption of SQL and file data at rest, authentication of users etc. (automated management on new user signup pref).
I can't really help on the certificates, but you will indeed need some "master certificate". If you are planning on using Azure website, you can't use your own certificates currently.
Concerning the database setup. SAAS applications build on trust, so you NEVER (EVER) want to be showing or editing the data of using to other users.
Therefore I strongly suggest that you don't use the TenantID for each table. This would leave still the possiblity of an attack by a malicious user or an error by some developer.
The only way to get around these risks are
extensive testing
physical different tables to store each tenant data.
Personally I believe that even with very extensive+automated testing you can't have 100% code coverage against malicious users. I guess I am not alone.
The only way out IMHO is physical different tables. Let's look at the options:
different server: valid, but pretty expensive in azure
different database: valid, less management overhead but same objection as the previous option - expensive if you have a lot of tenants
different schema's: the solution. Think about it...
you only have to manage users and there default schema's
you can back-up schema's using powershell
you can move schema's to other databases with some work
You can still digg into SQL federation if you need to.
the major drawback is that you will need to support database upgrades for each tenant.
Have you read on azure.com any articles about multi-tenancy? http://msdn.microsoft.com/en-us/library/windowsazure/hh689716.aspx
I'm a lead developer on a project which is building web applications for my companies SaaS offering. We are currently using LDAP to store user data such as IDs, passwords, contanct details, preferences and other user specific data.
One of the applications we are building is a reporting service that will both collect and present management information to our end users. Obviously this service will require a RDBMS but it will also need to access user data stored in LDAP.
As I see it we have a two basic implementation options:
Duplicate user data in both LDAP and the RDBMS.
Have the reporting service access LDAP whenever it needs user data.
Although duplicating data (and implementing the mechanisms to make this happen) as suggested in option 1 seems the wrong way to go, my gut feeling is that option 2 would not perform well enough (how do you 'join' LDAP data to RDBMS data as efficiently as a pure RDBMS implementation?).
I did find a related question but I'm still unsure which approach to take. I'd be interested in seeing what people thought of either option or perhaps other options.
Why would you feel that duplicating data would be the wrong way to go? Reporting tools (web based and otherwise) are mostly built around RDBMS's, so any mix'n'match will introduce unnecessary complexities. Reports are likely to need to be changed fairly frequently (from experience), so you want them to be as simple as possible. The data you store about users is unlikely to change its format very often, so once you have your import function working, you won't need to touch it again.
The only obstacle I can see is latency: how do you ensure that your RDBMS copy is up to date? You might need to ensure that your updating code writes to both destinations. Personally, also, I wouldn't necessarily use LDAP for application specific personal preferences: LDAP can't handle transactions, so what happens when data is updated from several directions? (Transactionality is of course also a problem with letting updaters write to both stores...) I'd rather let the RDBMS be the master for most data, and let LDAP worry only about identity, credentials and entitlements, which are rarely changed and only for one set of purposes. For myself, LDAP's ability to deal with hierarchical data isn't all that great a selling point.
Data duplication is not always a bad thing, especially when the usage scenarios are different enough.