Is it possible to store user (and therefore use in e.g. asp.net) a staff hierarchy in active directory e.g. staff > manager relationships.
My active directory install is relatively flexible, so I could add additional information.
It's certainly possible to extend the AD schema to support what you want to do, but I would seriously consider why you want to do it, and how many changes you might make down the road (not to mention how unhappy your system administrator might be after these changes).
The presence of AD is not a prerequisite to using built-in Asp.net authentication methods (although it makes integrated authentication much easier). If this kind of data is application specific, I would recommend looking into maintaining the data in an application-specific database. In doing so, you could pull the current user's FQDN from the HttpContext.Current.User, and key on the Name property of the associated Identity. For example:
HttpContext.Current.User.Identity.Name
From that point, you simply create a UserProfile table with associated organizational structures (i.e. a column for ReportsTo that acts as a reference to another UserProfile.
Related
I need some advice on how best to implement a security mechanism in a ASP.net core application. The application users are authenticated using AD authentication. Is there a best practice for this type of implementation?
I have a list of project records. Users should only be able to retrieve a list of projects that they have permission to access. I have three user types that have different levels of access as detailed below.
Approvers – assigned to individual projects.
State approvers – Can view state-wide projects.
Global approvers – Can access all projects.
Does anyone have any suggestions on what model and logic to implement to achieve what is required?
Well, I secure pages with information "limited" to logged on users. So if they have membership in a particale role, then only those users can jump/see such pages.
However, in your case, and often?
Well, it not so much the web page the user can use, or be restricted from.
However, when a web page can be restriced based on IIS security and not your code, then that option should be used.
However, often in code, for example, we have indivdul users from a given company, and ONLY some can and are allowed to see all projects. (so some only can see their own projects, but from that company, some have rights to see + use all projects.
So, we often have code say like this:
Dim cmdSQL As New SqlCommand("dbo.GetProjects", GetCon)
cmdSQL.CommandType = CommandType.StoredProcedure
cmdSQL.Parameters.Add("#LogonID", SqlDbType.Int).Value = Membership.GetUser.ProviderUserKey
cmdSQL.Parameters.Add("Email", SqlDbType.NVarChar).Value = Membership.GetUser.Email
cmdSQL.Parameters.Add("#PortalMaster", SqlDbType.Bit).Value = IIf(Roles.IsUserInRole("PortalMaster"), 1, 0)
so, if the user is a PortalMaster, then they can get and see all projects belonging to that company. (each company that logs into teh site can have 1 or 20 employees that belong to the given company).
So, in above, the query going to pull projects by EmployeeID (their logon), and thus they can only ever see their own projects.
If you are a member of the PortalMaster group, then we pull projects based on ComapnyID.
So, while you might not be using the older secuirty provider like above? Your queries that pull projects simple have to restrict rows returned based on above.
Once those projects are returned (in a nice grid - searching options included), then they can select (click on) a project. that next page does not really care anymore, since you can't get to the project details page until you selected a project.
So, obvious you must have for a given Project who created it. And thus your ability to display their current projects will be restriced based on their logon ID or whtever you using now.
But, for state level users? Then your critera is by their logon id and their state they belong to based on that logon.
And then there is the "admin" role or group - they can search and pull on all projects.
So, while we do restrict web pages by "role" security (based on IIS), that just means that all users can, or cannot hit some web pages based on their role memember ship (and such security does not require code on my part - the IIS secuirty assinged to those web pages can do all that dirty work for you.
However, if you are a legal logon, then you can only ever work on projects that belong to your company. But then it is a question if that user also has the role of "PortalMaster", and if they do, then we pull all projects for display to select from for that given user.
And of course we never use say URL "query parameters", and such internal database company ID, or ContactID (user id) are never exposed, nor possible allow display of information or data that don't belong to the given user.
So, you need to build some sql or some store procedures, and having a few "parameters" for those stored procedures that returns rows of data based on their role membership is quite much how you would approach this. So in above, if the user is a portal master, then the stored procedure simple queries the data based on company they belong to as opposed to their contact id.
Now, this of course asseumes the database schema is setup, and for example, we hvae a company table, a employee table (that has their logon information), and then of course each project created has both a created by, and the company the project belongs to. So, that simple information is enough to provide the 2 levels of security.
We actually don't have a "super user" that can look at and see all projects in the system, but it actually not all that bad of a idea, since for testing, or checking a project that has some problem is a "pain" right now, since we in theory have to create a logon for that company, or get a password.
So, all logons we create belong to a given company. And thus when a user creates a new project, it can only be created under that one company, and of course a project also requires the user that created the project.
So, you simple have to restrict records returned in the page in which they can select a project to work on. IIS security, or in fact SQL server security as a general rule can't do this type of security for you - you the developer have to.
The ability to add, update, and delete various entities in my application is often determined by the relationships defined between the various users involved. Here is an example:
A basic user or his supervisor can create tasks associated to the user, but only his supervisor can lock down the task so that the basic user will not longer be able to add/update/delete it. Until locked down, both individuals will be able to update the task.
What is the best approach to implement these kind of complex and advanced rules that deal with the relationship of users and the state of the entities (new, existing), as well as other things like maybe a user-defined status associated to the entity?
Thanks
What is the best approach to implement these kind of complex and advanced rules that deal with the relationship of users and the state of the entities (new, existing), as well as other things like maybe a user-defined status associated to the entity?
You want to use an authorization standard, namely XACML, the eXtensible Access Control Markup Language. XACML is:
a standard developed by OASIS, just like SAML is
a standard that focuses on fine-grained access control: access control that takes into account user information, resource information, state, and contextual information
a standard that implements the attribute-based access control (ABAC) model: the user information, resource data, and state can all be seen as attributes
a standard that uses policies and rules to structure the attributes and grant / deny access: XACML is policy-based
a standard that can be applied across multiple layers e.g. across the presntation tier, the data tier, the business tier of an MVC application
a standard that can be applied to multiple technologies and languages e.g. C# (MVC4 and more), Java, Python...
With XACML, you can easily implement relationships e.g.: an employee can approve a transaction if and only if the transaction amount < employee approval limit AND the transaction is not locked.
Where to go from here?
Check out NIST's page on ABAC.
Check out OASIS XACML's page and spec
Check out existing implementations (open-source and vendor such as the one I work for, Axiomatics.)
At a bank I worked for, we had a loan management system that allowed the entire bank hierarchy to see loans in their reporting structure. For instance, a Market exec could see the loan portfolio of all of his/her reports at once. Additionally, s/he had the ability to select from a list of all reports' (direct or indirect) names to view the portfolio of that employee.
It was complex, but we had to maintain an HR database of the reporting structure. Once we had that, we built user functions (could be done as stored procs, too, but user functions worked well in our LINQ to SQL backend) that allowed us to check whether user x supervises user y.
So, in your example, as long as you know who owns the task, and have access to a method that can be used to determine if the task owner reports to the currently-logged-in user, you should be able to easily enable/disable the "lock" button on the page.
The legwork lies in creating that reporting structure DB, and keeping it up to date!
We are currently transitioning our website to Drupal 6.x from a non Drupal source. One of the first issues we need to deal with is that of authentication. We have a central database where we keep member information. We will create a module to authenticate against this database however a question of whether or not to create users in the drupal is needed.
I'm worried that if we do not add user to the user tables and have our module keep sync that with the other database, then we will not be able to take advantage of other modules that may use the user module
My colleague on the other hand believes that this is not an issue we can add all necessary attributes to the global $user at authentication with our module.
Is there a standard way of dealing with this problem?
Thanks!
David
Look at the LDAP_integration module, they do something similar. When logging in and a local user cannot be loaded, a user is searched for in another application and when user&pass are equal, the user is copied in the Drupal usertable.
If you want any Drupal functionality (read: core and modules) to be associated with that user account, then you will need to use that user table.
This is especially true for anything node-related, so if you want people to be able to create nodes with referenced data you will need it. uids are stored in the nodes table in order to show who authored the node. Storing a uid in the nodes table with a something that doesn't exist as a relational key to somewhere else will only return an empty object. For instance, if a person wants to see the author of X node they will get an empty user object. Keep it. There's no sense in working harder just to remove it. Besides, you can store as little or as much as you want in the user object for each account.
I'd also suggest looking at the LDAP module. I was able to use it as a jumping in point to interface with a custom WSAPI authentication method for an external database that we have at my company.
Do you need to have both sites running in parallel? If not, then you don't need to sync the user tables. A conversion will be enough then.
My company is building an ASP.NET HR application and we have decided to create one database per client. This ensures that clients cannot accidentally view another client's data, while also allowing for easy scalability (among other benefits, already discussed here).
My question is - what is the best way to handle security and data access in such a scenario? My intent is to use a common login/account database that will direct the user to the correct server/database. This common database would also contain the application features that each user/role has access.
I was not planning to put any user information in each individual client database, but others on my team feel that the lack of security on each database is a huge hole (but they cannot articulate how duplicating the common access logic would be useful).
Am I missing something? Should we add an extra layer of security/authentication at the client database level?
Update:
One of the reasons my team felt dual user management was necessary is due to access control. All users have a default role (e.g. Admin, Minimal Access, Power User, etc.), but client admins will be able to refine permissions for users with access to their database. To me it still seems feasible for this to be in a central database, but my team doesn't agree. Thoughts?
We have a SaaS solution that uses the one DB per client model. We have a common "Security" database too. However, we store all user information in the individual client databases.
When the user logs into the system they tell us three pieces of information, username, password and client-id. The client-id is used to lookup their home database in the "security" database, and then the code connects to their home database to check their username/password. This way a client is totally self-contained within their database. Of course you need some piece of information beyond username to determine their home database. Could be our client-id approach, or could be the domain-name requested if you're using the sub-domain per client approach.
The advantage here is that you can move "client" databases around w/out having to keep them synced up with the security database. Plus you don't need to deal w/cross-db joins when you're trying to lookup user information.
Update: In response to your update... One of the advantages to each customer having their own DB is also the ability to restore a customer if they really need it. If you've split the customer's data into two databases how do you restore it? Also, again, you'll need to worry about cross-db data access if the users are defined in a DB other than the home DB.
I've always been of the opinion that security should be enforced at the application level, not the database level. With that said, I see no problem with your intended approach. Managing accounts and roles through a central database makes the application more maintainable in the long run.
You may want to look into using the ASP.NET membership provider for handling the authentication plumbing. That would work with your stated approach and you can still keep all of the authentication data in a separate database. However, I agree with Chris that keeping one DB will utlimately be more maintainable.
I am looking for a best practice for End to End Authentication for internal Web Applications to the Database layer.
The most common scenario I have seen is to use a single SQL account with the permissions set to what is required by the application. This account is used by all application calls. Then when people require access over the database via query tools or such a separate Group is created with the query access and people are given access to that group.
The other scenario I have seen is to use complete Windows Authentication End to End. So the users themselves are added to groups which have all the permissions set so the user is able to update and change outside the parameters of the application. This normally involves securing people down to the appropriate stored procedures so they aren't updating the tables directly.
The first scenario seems relatively easily to maintain but raises concerns if there is a security hole in the application then the whole database is compromised.
The second scenario seems more secure but has the opposite concern of having to much business logic in stored procedures on the database. This seems to limit the use of the some really cool technologies like Nhibernate and LINQ. However in this day and age where people can use data in so many different ways we don't foresee e.g. mash-ups etc is this the best approach.
Dale - That's it exactly. If you want to provide access to the underlying data store to those users then do it via services. And in my experience, it is those experienced computer users coming out of Uni/College that damage things the most. As the saying goes, they know just enough to be dangerous.
If they want to automate part of their job, and they can display they have the requisite knowledge, then go ahead, grant their domain account access to the backend. That way anything they do via their little VBA automation is tied to their account and you know exactly who to go look at when the data gets hosed.
My basic point is that the database is the proverbial holy grail of the application. You want as few fingers in that particular pie as possible.
As a consultant, whenever I hear that someone has allowed normal users into the database, my eyes light up because I know it's going to end up being a big paycheck for me when I get called to fix it.
Personally, I don't want normal end users in the database. For an intranet application (especially one which resides on a Domain) I would provide a single account for application access to the database which only has those rights which are needed for the application to function.
Access to the application would then be controlled via the user's domain account (turn off anonymous access in IIS, etc.).
IF a user needs, and can justify, direct access to the database, then their domain account would be given access to the database, and they can log into the DBMS using the appropriate tools.
I've been responsible for developing several internal web applications over the past year.
Our solution was using Windows Authentication (Active Directory or LDAP).
Our purpose was merely to allow a simple login using an existing company ID/password. We also wanted to make sure that the existing department would still be responsible for verifying and managing access permissions.
While I can't answer the argument concerning Nhibernate or LINQ, unless you have a specific killer feature these things can implement, Active Directory or LDAP are simple enough to implement and maintain that it's worth trying.
I agree with Stephen Wrighton. Domain security is the way to go. If you would like to use mashups and what-not, you can expose parts of the database via a machine-readable RESTful interface. SubSonic has one built in.
Stephen - Keeping normal end users out of the database is nice but I am wondering if in this day and age with so many experienced computer users coming out of University / College if this the right path. If someone wants to automate part of their job which includes a VBA update to a database which I allow them to do via the normal application are we losing gains by restricting their access in this way.
I guess the other path implied here is you could open up the Application via services and then secure those services via groups and still keep the users separated from the database.
Then via delegation you can allow departments to control access to their own accounts via the groups as per Jonathan's post.