I understand there is a Domino ini setting for turning off all FT-indexing for an entire server. But is there any way to do this for only some databases on the sever, possibly on a per folder basis?
A fulltext can only be created by a user with manager access to the database.
In a well configured environment NO USER needs manager access to ANY database.
Even administrators don't need that (as there is Full Administration Mode).
So: Give users editor to the databases, manage access to databases with groups (user managed groups if you want), and then decide which databases to index.
In the end give the rules about which databases should have an index to the admins...
I'm trying to setup customer access to some of my BigQuery data. I'll start off with my requirements, then what I think the solution needs to be, though I'm not sure how to execute.
Requirements
Separate billing per customer for queries
I don't want to make my dataset public
Read only access to specific datasets
Accessible via Excel connector
No access rights to my main project
They manage their own access privileges, I don't want to have to add and remove individual users from direct dataset access on behalf of all our clients.
Nice to have - Web UI access
What I've Done
Created a new Google Developer Project
Added a view-only user on that project
Added a service account
Granted access to my BigQuery dataset to the service account
Here are the options for granting dataset access from the documentation:
I imagine that I need to setup some sort of special group, but I can't figure out how to do it.
Thanks in advance!
In BigQuery there are two different concepts:
The first one is billing (for queries and any other billable
activity) that is linked with a Google Cloud Project.
The second one is access to a dataset.
Having said that, to fulfil your requirements you'd create a separate project for each of the customers, and grant access to the datasets in the granularity that you would want.
That way you would have the costs for each of the projects separated but billed to you. Be careful to give them only read access to the project, unless you want them to be able to create other services like VM or deploy GAE apps, as they'd be billed to you as well.
For example dataset [MyDatasetA] to users X and Y in projects Project1 and Project2, but access to [MyDatasetB] to users Y and Z in projects Project2 and Project3.
Thus, each project is accountable for the queries their users run, and you have your access control on each dataset without it being public.
Separate billing per customer for queries. Done with the independent projects.
I don't want to make my dataset public. Done with fine grained control access.
Read only access to specific datasets. Same as above.
Accessible via Excel connector. It should work without problems as they'd be first class BQ users.
No access rights to my main project. Again possible if they are restricted to their own projects.
They manage their own access privileges. This is trickier. I think they'd need more than read access to the datasets or more than read access to the projects to be able to add new users, if you use the project groups as access control.
Nice to have - Web UI access. Check out https://bigquery.cloud.google.com/
The project groups are groups that allow to select members with Viewer, Developer or Owner roles in one click, without the hassle of adding each member manually.
You get already three groups set-up for you to use: Viewers, Editors and Owners of the original project.
But you may create your own Google Groups and give those groups the permission you want.
The hint when doing so, is that new users will usually need to Display your project so that it appears in the BQ online browser. This is done by clicking on the arrow to the side of the project name in the BQ online browser followed by Switch to project then Display project with the project name that the Dataset belongs to.
Edit: Improved the explanation about Group access
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
Here's a question that I have been wrestling with for a while. We have a situation wherein we have a number of applications that we have created. These have grown organically over a period of time.
All of these applications have permissions code built into them that controls access to various parts of the application depending on whether the currently logged in user has the necessary permissions or not.
Alongside these applications is a utility application which allows an administrator to map users to permissions for all applications - the way it works is that every application has code which reads this external database of the said utility application to check if the currently logged in user has the necessary permission or not.
Now, the question is this. Should the user-permissions mapping information reside in and be owned by the applications themselves, or is it okay to have this information reside within an external entity/DB (as in this case the utility application's database).
Part of me thinks that application permissions are very specific to the application context itself, so shouldn't be separated from the application itself. But I am not sure.
Any comments?
You should read up on federated identity, which is the new trend.
We have for over 10 years maintained a library we used across all applications which centralized user authentication and authorization. It is loosely coupled to AD and has centralized roles and rights that are managed by the user community based on business needs and not the network personnel.
Our design has afforded us the ability to embrace the new trends on federated identity practices along with claims based identity and simply update our library allowing all applications, some of which are written VB6 to use current security requirements.
I know that LDAP is used to provide some information and to help facilitate authorization.
But what are the other usages of LDAP?
I will focus on why using LDAP, not what is LDAP.
The use model is similar like how people use library cards or phonebooks. When you have a task that requires “write/update once, read/query many times”, you might consider using LDAP. LDAP is designed to provide extremely fast read/query performance for a large scale of dataset. Typically you want to store only a small piece of information for each entry. The add/delete/update performance is relatively slower compared with read/query because the assumption is that you don’t do “update” that often.
Imagine you have a website that has a million registered users with thousands of page requests per second. Without LDAP, every time users click a page, even for static page viewing, you will probably need to interact with your database to validate the user ID and its digital signature for this login session. Obviously, the query to your database for user-validation will become your bottleneck. By using LDAP, you can easily offload the user validation and gain significant performance improvement. Essentially, in this example, LDAP is another optimization layer outside your database to enhance performance, not replacing any database functions.
LDAP is not just for user validation, any task that has the following properties might be a good use case for LDAP:
You need to locate ONE piece of data many times and you want it fast
You don’t care about the logic and relations between different data
You don’t update, add, or delete the data very often
The size of each data entry is small
You don’t mind having all these small pieces of data at a centralized place
That's a rather large question.
LDAP is a protocol for accessing a directory. A directory contains objects; generally those related to users, groups, computers, printers and so on; company structure information (although frankly you can extend it and store anything in there).
LDAP gives you query methods to add, update and remove objects within a directory (and a bunch more, but those are the central ones).
What LDAP does not do is provide a database; a database provides LDAP access to itself, not the other way around. It is much more than signup.
Well, there are LDAP servers and the LDAP protocol. Combined, it's a data store, or a database. It's not relational, but it's just a place to store data, and it's optimized to be efficient at reads more than writes. It doesn't support transactions.
Now, it happens to be very popular for storing credentials, but that's by no means its only purpose, and not its original purpose.
LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lightweight protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. The nitty-gritty details of LDAP are defined in RFC2251 "The Lightweight Directory Access Protocol (v3)" and other documents comprising the technical specification RFC3377. This section gives an overview of LDAP from a user's perspective.
What kind of information can be stored in the directory? The LDAP information model is based on entries. An entry is a collection of attributes that has a globally-unique Distinguished Name (DN). The DN is used to refer to the entry unambiguously. Each of the entry's attributes has a type and one or more values. The types are typically mnemonic strings, like cn for common name, or mail for email address. The syntax of values depend on the attribute type. For example, a cn attribute might contain the value Babs Jensen. A mail attribute might contain the value babs#example.com. A jpegPhoto attribute would contain a photograph in the JPEG (binary) format.
How is the information arranged? In LDAP, directory entries are arranged in a hierarchical tree-like structure.
LDAP is the Lightweight Directory Access Protocol. Basically, it's a protocol used to access data from a database (or other source) and it's mostly suited for large numbers of queries and minimal updates (the sort of thing you would use for login information for example).
LDAP doesn't itself provide a database, just a means to query data in the database.
The main idea of LDAP is to keep in one place all the information of a user (contact details, login, password, permissions), so that it is easier to maintain by network administrators. For example you can:
use the same login/passwd to login on an Intranet and on your local computer.
give specific permissions to a group of user. For example some could access some specific page of your Intranet, or some specific directories on a shared drive.
get all the contact details of the people in a company on Outlook for example.
The main benefit of using LDAP is that information for an entire organization can be consolidated into a central repository. For example, rather than managing user lists for each group within an organization, LDAP can be used as a central directory accessible from anywhere on the network. And because LDAP supports Secure Sockets Layer (SSL) and Transport Layer Security (TLS), sensitive data can be protected from prying eyes.
LDAP also supports a number of back-end databases in which to store directories. This allows administrators the flexibility to deploy the database best suited for the type of information the server is to disseminate. Because LDAP also has a well-defined client Application Programming Interface (API), the number of LDAP-enabled applications are numerous and increasing in quantity and quality.
LDAP main usage is to provider faster retrieval of data . It acts as a central repository for storing user details that can be accessed by various application at same time .
The data that is read various time but we rarely update the data then LDAP is better option as it is faster to read in it because of its structure but updating(add/updatee or delete) is bit tedious job in case of LDAP
Security provided by LDAP : LDAP can work with SSL & TLS and thus can be used for sensitive information .
LDAP also can work with number of database providing greater flexibility to choose database best suited for our environment
Can be a better option for synchronising information between master and its replicase
LDAP apart from supporting the data recovery capability .Also , allows us to export data into LDIF file that can be read by various software available in the market
I have had the opportunity to start a project for school about ldap, from scratch, but before getting to know what is ldap, I had to understand what is a directory, there are many (most used directories are novell and windows), here you can see what the directory in Wikipedia.
And ldap is the protocol to communicate with the board, one of the best books I've found is this one.
LDAP is just a protocol to access structured information. LDAP has standardized local and remote access to information whereas in case of database there is only standardized local access and remote access is proprietary.
LDAP server is optimized for search operation and database for transactions(Insert/Delete).
For more information refer following link:
http://www.itszero.in/2013/09/what-is-ldap-ad-adam.html
In Windows Server LDAP is a protocol which is used for access Active Directory object, user authentication, authorization.
To take the definitions the other mentioned earlier a bit further, how about this perspective...
LDAP is Lightweight Directory Access Protocol. DAP, is an X.500 notion, and in X.500 is VERY heavy weight! (It sort of requires a full 7 layer ISO network stack, which basically only IBM's SNA protocol ever realistically implemented).
There are many other approaches to DAP. Novell has one called NDAP (NCP Novell Core Protocols are the transport, and NDAP is how it reads the directory).
LDAP is just a very lightweight DAP, as the name suggests.
Well,
LDAP is a protocol(way) to access structured info. LDAP uses client-server model so, LDAP client makes request to access required info. LDAP server stores info not in relational way but in attribute and value pair. You can use LDAP to assign same privilege to group of user or same credential to access multiple services. For more details refer following link : http://www.zytrax.com/books/ldap/ch2/
LDAP stands for Lightweight Directory Access Protocol.It is used in Active Directory for communicating user queries..e.g.. LDAP can be used by users to search and locate a particular object like a laser printer in a domain.
LDAP is also used to store your credentials in a network security system and retrieve it with your password and decrypted key giving you access to the services.
Light weight directory access protocal is used to authenticate users to access AD information
LDAP stands for Lightweight Directory Access Protocol (not a database). As the name says it is used for accessing/reading data. LDAP is a protocol to access data from directory servers which is a hierarchical database, it is designed for reading, browsing, searching, and organizing data. This kind of data we do not modify regularly or it is very infrequently modified data.
Big companies store their internal data, for example, user names with their title and id or phonebooks of their workers on LDAP servers (this server implements a tree-structured database). Those data can be reached by the workers of that company through the LDAP protocol. LDAP protocol runs over TCP or UDP protocol and accesses the server through port 389. There is also LDAPS that runs over SSL and accesses the server through port 636.