In response to a question I asked about a week ago I changed our database engine to only accept Windows Authentication instead of SQL Authentication. Because our code runs in a different user context then that of the database connection we need to specify the username and password information in order for us to connect to the database. How do we do this using a ConnectionString? Remember, we are not using SQL Authentication anymore.
Thanks,
On your SQL Server instance, you need to add the domain group under the Security node (the one in the main server group, not in the individual databases). Under that node, the end result would be an item that resembles
<Your Domain>\Domain Users
Then in your application (Windows or Web) connection strings you want to set integrated security to be TRUE, and elsewhere, you need to set Impersonation to also be True. I am being vague here because the methods vary by application type.
Hopefully that sets you on the correct path.
Since you are using only Windows authentication, you can't in the connection string. The calling process will need to impersonate a windows principle (user) with the relevant access permissions.
Related
I have made a Java ExtLib XPage custom REST service (CustomServiceBean) database basing on this solution: https://setza-projects.atlassian.net/wiki/spaces/RS/pages/363593730/IBM+Domino
I modified it though to use NotesCalendar class to create, update and delete events & resource reservations (so everything in fact is processed by the calendar, I'm only using raw documents for reading $Rooms in names.nsf and $Reservations in the reservations database). Everything works fine so far, it uses current session to open the calendar. I have some concerns regarding the permissions though.
What I want (and need):
Ability to create calendar events & reservations as SPECIFIC users, I don't want just one "main" user that will create everything. I want each IBM Lotus user to be able to login with their credentials and create or update their calendar events.
This database with XPage will be deployed on our client's servers, so I don't want to require some special configuring for each user in order to be able to access my REST service.
I set up a new local installation of Lotus Server and created a new application using my XPage database as template, and I couldn't access the API neither with admin account or other accounts:
HTTP JVM: CLFAD0229E: Security exception occurred servicing request for: /db.nsf/services.xsp/api - HTTP Code: 403. For more detailed information, please consult error-log-0.xml
As soon as I added my admin account to Server configuration -> Security -> Sign or run unrestricted methods and operations, it started working again. Not only for the admin account, but also for other accounts that were just created with an internet password and weren't assigned any specific roles or permissions. I didn't even sign the database.
So my question is, is this enough in order to get it working on client's production server? It kind of makes no sense to me, but it worked on my local server so I'm not sure, I'm new to IBM Lotus and I'm just doing an integration REST service.
If not, how could I do it, so I wouldn't really need to put the end client (Lotus server owner) into the hassle of configuring each user, while still being able to access the API as any Lotus user (providing the username and password)? I can either log-in as each indepentend user, or perform some impersonation with a "main" privileged account (create entries in someone else's calendar as him), although I think there is no way to do it in Java, because .getCalendar is a method of the Session class, I tried using createSession(), but I wasn't able to.
Every notes application needs to be signed by an administrator with an ID known to the customers environment. The Id which is used to sign the db must have the appropriate rights, through the security tab in the server document. If the app is not signed properly, the app won't run. Once the app is signed, it runs in the authorized users session with the users rights.
I am trying to use the new authentication system and I cannot find any decent articles/documentation to get what i want. Plenty of stuff out there explaining how the authentication process works out of the box but realistically you will need more.
First of all how do you control which database you store user information? I have read in many place that you can add a connection string. Ok great, but how do you get that connection string to be used by the authentication system?
And how would this work in a web farm, assuming user account information is split across databases with a little piece of logic which decides which database a user should login against?
I have used keystone extensively and it really isnt bad to implement. Its the authentication mechanism of Openstack. Check it out here http://docs.openstack.org/developer/keystone/
To answer your question users would first authenticate with it, receive a token, then they would present their token at any of your servers. If your data is split up, you can configure keystone to only allow access to certain areas of you backend via groups.
Changing the underlying database needs to steps. You have to add the connection string for the database you want to use for Identity. After this you have to change the base constructor call in your DB context to pass your new connection string to the base class (this is your missing step). An example for it is shown in this thread.
For your second question I don't have a good answer, because I haven't used Identity in a multiple DB servers scenario yet.
We have c# web app connecting MongoDb deployed on Linux server. The idea is to use single designated Linux account for our web application to login and connect into MongoDb. As I understand from what I read, MongoDb does not support integrated security at all by default, it supposed to have its own user database with passwords, and no roles too, right? If so, I wonder if there is any separate third-party framework/tool or something that helps me use desired approach?
Other than that, if you know good online article regarding best practices to implement Security for Mongo in web applications, like where and how to store users and encrypted passwords etc., please give me a link.
please give me a link.
I did some security documentation a few months ago for MongoDB and it can be found here, this should be your starting point.
As I understand from what I read, MongoDb does not support integrated security at all by default, it supposed to have its own user database with passwords, and no roles too, right?
Up until MongoDB 2.2, authentication and authorisation is all local.In 2.2, there is limited RBAC (Role Based Access), i.e. two roles "read" and "write", with "write" being able to do everything on that database, i.e. admin.
Things will change in 2.4 with new roles:
name description of privilege
read ability to query data in any collection in the database, other than 'system.users', and also ability to run any command without an A or W attribute
readWrite everything permitted by 'read' privilege, and also the ability to insert, update,
or remove documents or indexes in any collection other than 'system.users', and also the ability to run any command without an A attribute
userAdmin ability to read and write the 'system.users' collection
dbAdmin ability to run admin commands affecting a single database; see list below
serverAdmin ability to run admin commands affecting the entire database server; Can only be set on admin database; see discussion
clusterAdmin admin commands for a cluster of shards or a replica set; Can only be set on admin database
as documented here. This enhanced RBAC will be available in all versions of MongoDB from 2.3.2 (development build) and the next production release, 2.4.0.
With MongoDB 2.4, there will also be the ability to use Kerberos for authentication, however, this delegated authentication will only be available in the Enterprise builds, which require a Commercial Support contract for us.
There is currently nothing within MongoDB that enforces password complexity but obviously in 2.4 with Kerberos, the KDC can do this. You will manually have to ensure (through your internal password policy etc) that users realise the issues of using non-complex passwords and re-using the same passwords on multiple devices. Assuming you are running 2.2, all logins, passwords and permissions for MongoDB access are stored in the system.users collection under each database. Here is the exact link to the documentation that you should read.
Background
We have a WinForms application with Entity Framework 4.2 code-first / FluentAPI using SQL Server 2008 R2.
The security is a custom implementation of IPrincipal and IIdentity with the roles for the user. These roles are checked when a Form/menu/button is displayed and it will be disabled/removed based on the user role.
Users are authenticated against the database so there is no "master" user for the connection: it's created using the username/password provided on the login screen.
So, access to data (general) is working.
The problem
But some cases might require me to disable access to a specific table or to a column inside the table.
Some tests have shown here that IGenericRepository.Find<MyCustomType>(_idToFind) (which returns the complete entity) will fail because there is no access to a single column and SQL server will prevent the whole select statement.
I've found, however, that create a query like
IGenericRepository.All<MyCustomType>().Select(_c => _c.JustASingleField)
will work because the generated query will look only for a specific field for which I have access.
Question
Is there a way for me to create queries that will be role-aware to the database?
For instance: Find<MyCustomType>(id) will return the object as usual but with the field that the user does not have access set to NULL or with no value?
Or I'll just have to write "generic" queries for every single item that does not require protection and rely on the security system to completely block access to a resource?
Another example would be to fill a grid but the column for which the user does not have access will be blank.
Is it possible at all using Entity Framework?
Is it possible at all using EntityFramework?
No. EF is not aware of security configuration on SQL server and it is not able to react to any security demands expected by SQL server except providing credentials for connection string.
If you require this type of security you should use database views providing only accessible items to specific role and let EF to use model mapping only views the user role has access to - it can result in quite big set of different "models" due to many roles.
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.