I understand LDAP is the protocol which is used to talk to an active directory system like OpenLDAP.
I also understand OpenLDAP is a kind of database which stores objects in a tree.
My question is: When and for what should I use (if at all) LDAP instead of a relational DB.
A relational database and a LDAP based database solve different issues. LDAP is strongly focused on fast-read, slow write, it's hierarchical, distributed, and based on authority (like DNS). If your data don't match this assumption, LDAP is not the right choice.
LDAP works well to describe a hierarchy of entities, like for example a company addressbook. While a relational database would require every department to access the big global table with all the addresses, an LDAP solution allows to distribute the responsibility of each department's addressbook to the department itself, while keeping it available for query to anyone else in the company.
LDAP allows you to store any kind of information. The addressbook is the most typical example, but everything that can be intended as hierarchical, authority-focused dataset can be stored in LDAP. Another example: suppose a library is part of a consortium of libraries, and they want to store data about the books they have. The database is hierarchical (each library is authoritative within its borders) and each library is independent from the others. Inside the schema, you can store data about the books, such as author, publication year, title, isbn and so on.
To store data, you represent it using a special file format, LDIF, but APIs exist as well. LDIF, however, is the most easy way to see the information. it's just a plain text file. An example from wikipedia
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john#example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
This describes the information about a guy called John Doe. It is under the "realm" of dc=example, dc=com, and has a bunch of other information associated to it (think like a table row). Note that the hierarchy can be (apparently) associated to internet domains, like in this case, but in reality the hierarchy description is very flexible. You can organize hierarchies based on national borders or company departments, or anything you like, as you prefer.
You should use LDAP when you need to manage a data domain where you have
the need for a flexible schema with reduced storage requirements.
reduced write needs, strong read needs
strong hierarchical nature of management and organization of information
authorities and delegation of authoritativeness
This concise and nice post has very good info relating to this scenario.
If interested further, you can go a bit deeper in here, which is a continuation to the above link.
LDAP is good for data which is frequently read and rarely written. For example, LDAP is often used to store user login or password information.
LDAP is a centralized user and account management system which can also store some data fields.
You can use LDAP also as lookup-addressing mechanism to retrieve resources, for example Database-Connections or remote-services.
The nice thing I like about LDAP is, that you can retrieve stuff in directory/URL style. This is quite different to RDBMS where you have to use a dedicated query-language. This often makes sense and is intuitive if things are organized in a hierachical way.
Related
I am using ABP Commercial to implement a custom CRM system. I am looking for an example, a best practice, a library, or even a framework for scoping data according to user IDs and roles.
Simple scoping like just showing entities created by a certain user is fairly straightforward. But what about showing increasingly more broad data based on a hierarchy of user roles.
For example, I might have a basic user role that can only see data created by the user in that role. Then, I might have a manager role that can see his own data and all the data created by the basic users he manages. Contemplating any decent size organization, you can see how this hierarchy might get quite deep.
So can anyone tell me whether there is a facility or module within ABP Commercial or ABP Framework to facilitate this kind of pattern or if there is third party best practice, library, or framework that might work in conjunction with my code to realize this functionality?
In the past I have written my own implementations but I am looking for a DDD or clean architecture based solution.
EDIT
A more specific example of what I'm trying to do is to create an extension of the user class and role class or to add additional entities managed by a domain service that would allow for:
users to have a collection of roles they manage and a collection of specific users they manage, and…
roles to have a collection of other roles they manage (think composite pattern)
These relationships would be used to filter all kinds of queries within my application.
Here are some use cases:
return a list of contacts associated with the clients of my direct reports
return a flattened list of all users managed by me or my reports
return the total revenue of all sales made by users managed by me or my reports
I'm new to LDAP but have a project that requires it*. I'm looking for suggestions on how to organize the database.
There are three components: users, sites and studies. A user belongs to one site and one study; a site can have multiple studies. A site can also have multiple domains (not just DN entries; they might have site1.org, site2.com, and so on.) Finally, some piece of identifying site and study information is being used in another database -- I can't use the name of the site or study but a UID of some sort would work fine.
My initial stab at this has users, sites and study information in three OUs; each entry has a UID guaranteed to be unique for that entity. Each user entry has a site and a study attribute but their distinguished name is "uid=[username],ou=users". Similarly, the site and studies have DNs "uid=[uidvalue],ou=[site|study]"
I have two questions:
1. Does the above schema make sense? I'm only a little ways along now and would like to make sure I'm on the right path before going too far.
2. How do I represent multiple domains for the site? It seems like multiple DN attributes would just be confusing, especially since they're simply attributes and not part of the distinguished name.
Thanks for your help!
-j
(*) Because various services on which the system relies use LDAP for authentication -- and, besides, it seems to make architectural sense anyway
I strongly recommend you use existing schemata. For example:
inetOrgPerson for people
organization or organizationalUnit for sites
domain for domains
not sure what is appropriate for study, possibly documentSeries or document.
To answer your questions:
Does the above schema make sense?
Yes. You should beware the tendency to use the hierarchy to represent possibly temporary organization of the objects in the tree. You should use attributes for that, as you are.
How do I represent multiple domains for the site? It seems like multiple DN attributes would just be confusing, especially since they're simply attributes and not part of the distinguished name.
I don't see that. Multiple DN entries are OK, or multiple domain sub-objects. If a site has multiple domains it isn't appropriate for domain to be part of the DN.
I am relatively new to chef, so I may be missing something extremely basic. After much searching I am not finding what I need, so here goes:
In Chef, I have roles that are conflicting. I need for all servers of a certain type to have roleA, except for servers with roleB.
The best way I can think of to describe it is with an example:
syslog1, syslog2
web1, web2, web3
db1, db2
mail1, mail2
Every server within this environment(dozens) has a role called syslog_client, except syslog1 and syslog2, which need to have the role syslog_server.
The syslog-server and syslog-client roles conflict, because they configure the same pieces of software differently.
These are roles rather than recipes because they actually encompass several recipes.
I thought of doing something like this:
roles/base.rb:
name "base"
description "base configuration"
override_attributes(
)
default_attributes(
)
run_list(
"recipe[one]",
"recipe[two]",
"recipe[three]",
"role[uno]"
)
unless node[:roles].include?('syslog_server')
run_list('role[syslog_client]')
end
The problem there is that the node object does not exist at this point. I have thought about moving it into the recipe, but I could not come up with a good way to do it there either. I was able to use this in the base recipe:
unless node[:roles].include?('syslog_server')
node[:roles]+=['syslog_client']
end
This adds syslog_client to the roles attribute (or doesn't) correctly, but it never actually runs the syslog_client role.
I have considered moving syslog_client into a self-contained recipe rather than a role, and moving the role attributes to the environment. This would work, because then I can just call include_recipe "syslog::client". The problem there is that virtually all of our recipes are assigned from roles (not from other recipes), and I fear that making this change will create a one-off that will be hard to keep track of. Besides that, as I mentioned already, these are actually several recipes, so adding them as a single recipe is not ideal.
We have many different server types/roles in the environment I'm currently working in, and adding role[syslog_client] to them is feasible, but not ideal. With multiple people working on this, it seems likely that someone will forget to add the recipe to a new role.
In an ideal world, something like my first solution would be possible, because that allows us to keep our environment as consistent as possible. I am open to other options though.
So to wrap up, I think what I need is someone to tell me how to:
Make the first solution work. Add a role to a run list only if another role is not present
If I cannot have #1, I'd like opinions on the best way to achieve this using the ways I've listed or other ideas I have not thought of
Please let me know if I'm missing any details about our chef setup that will be helpful.
Disclaimer: The above example is really a very simplified version of what I'm actually trying to achieve. I'm not even working with syslog, but the company it is for is very security-conscious and would not be happy with details of their environment being posted publicly. I will be as detailed as I possibly can if I've left anything out and I need to add further info.
Extending what was said above what's the issue with creating two roles. A Client and a server
The Client role includes the base role and the client function. It will get applied to all servers through replacing references to 'base' with this role in all other roles. Meaning those roles still get base but get client as well.
The server is a stand-alone role which only applies to those servers and has the base and then the server role?
That way both client and server get the base role applied to them without duplicating the definition of what the base role is. You still manage that base role as you want but you use aggregation in the creation of roles?
When a new role is created the user won't start by adding base but instead adding the syslog_client role which gives them base as well.
To me that feels like the way Chef is pushing you with the creation of roles. What we have is 1 role that applies to all servers, some that apply to 1 subtype of servers but not anothers. That way our leaf role as in the one that gets applied actually consists of 4 or 5 other roles. What's common is modelled in a way that can be shared without the need for logic within?
The other option would be to add the client recipe to every node and the first exeuction step is to check the nodes role and if it says server just basically skip the recipe execution? Which would be the same as the logic which you were wanting to use to add the recipe but it would live in the recipe and control the execution?
unless node[:roles].include?('syslog_server')
#Do your client install
end
I'm diving into RBAC while designing new and rather big/complex site.
I'm trying to figure out if to create a task or simply an operation with biz rule.
Now, I've read most if not all existing documentation. The current documentation says that "a task consists of operations". This wiki article says that the different terms are simply naming conventions and the only limitation that exists is structural one - roles must include tasks (or other roles); tasks should include operations (or other tasks) and operations is the atomic term that is not further composed by other entities.
I've also read the relevant sections in the "Agile web dev..." and "Yii cookbook" books - both do not shed further light on this issue (at least as seen through my glasses).
Lets go to my example where I'll present the question. Actually, lets use an example similar to that demonstrated in most of the documentation resources mentioned above: Lets say I have a blog post and I want/need to have its author be able to "update own post". Now, why should this be a task as commonly demonstrated in the documentation resources and not an operation with a biz rule?
I think that the question above reveals the inclear definition of a "task" (in the RBAC context of course).
Please help me distill a better definition for an RBAC task.
EDIT:
I was suggested the following definitions of the mentioned terms that help conceptualize them in a useful way. In short and in its simplest form: operations are the basic building blocks. They are the material developers work with and only them. Developers compose tasks of and on top of operations. Roles are composed of tasks, like a set of tasks. Roles and tasks are what the site administrators should play with - assign and revoke to users but not operations.
That's a nice way to look and grasp those entities (roles, tasks and operations).
Do you have another option to conceptualize differently? Any comments will be appreciated.
TIA!
Boaz.
I'd say the same as you did in your question edit. A task is simply a composition of operations a user can do that have something in common. So you have for example operations oList, oView, oCreate and oUpdate these are the operation developer assigns to controller actions for access control, where the first two are only read- and the second two have write access to data (that's what they have in common). So you now want to combine those to tasks tInspect and tManage which both hold 2 operations, the first one can list and view and the second one can create and update. Optionally you could make tInspect a sub-task of tManage so a user that has tManage can list, view, update and create but normally you just give his role both tasks.
Regarding the classification of role -> task -> operation, they are essentially the same thing, as you can see in the code they are of class CAuthItem. We name them differently mainly from user point of view.
Operations are only used by developers and they represent the finest level of permission.
Tasks are built on top of operations by developers. They represent the basic building units to be used by RBAC administrators.
Roles are built on top of tasks by administrators and may be assigned to users or user groups.
The above is a recommendation, not requirement. In general, administrators can only see tasks and roles, while developers only care about operations and tasks.
Check this out : http://www.yiiframework.com/forum/index.php/topic/2313-rbac-confusion/page_p_16035#entry16035
if there are two user
1)admin
2)user
so we set role updatePost for update page.
and admin is parent of updatePost so admin can update.
user have updateOwnPost permission.updateOwnPost is parent of updatePost with bizrule.so if bizrule satisfy he can update
I'm trying to make the domain model of a management system. I have the following kind of people in this system:
employee
manager
top mananger
I decided to define an User, from where Employee, Manager and Top Manager will specialize from.
Now, I don't know what kind of specialization hierarchy I should choose from.
I can't decide between the following ways:
or
Which might be preferable and why?
As a long time coder, every time I try to do a domain-model, I have to fight against the idea of trying to think in how I'm going to code this. From what I've understood, I should not think about those matters in the domain-model, only in object relationships. I don't have to think of code duplication or any of these kind of details here, so I can't really pick any of the options over the other.
Thanks
EDIT:
I'll be a bit more explicit: This is a program to manage worker's vacations plans. With this program, a employee can choose the set of vacations days for the year. Then the manager might approve or not those days for each one of the employees and at the end of the day the top manager should approve or disapprove the manager's decisions. This is all the users of my program are supposed to be able to do. There are no other tasks.
This mostly comes down to a question of how you define your terms. The basic question is whether a manager can be substituted for an employee under any possible circumstances -- and without knowing the precise rules of the workplace being modeled, it's impossible to say one way or the other about that.
One general notion is that yes, at least up to a certain point, in a pinch a manager should be able to do the job of any of his subordinates (at least one level below, and quite possibly two or three).
On the other hand, in some places with lots of union-driven rules in place, that may not be the case at all. Even if a person is entirely capable of doing a job, rules may prevent him from substituting in that position at all. In some cases this arises from certification requirements and such (e.g., the manager may have one been qualified to do the work, but the required certification has lapsed) or from things like union rules (e.g., a friend of mine who was once reprimanded because he carried a flashlight bulb and battery from the company store back to his lab instead of getting a union materials handler to do that for him).
In real life, Managers are Employees too. So this is surely just a chain of increasing specialisation:
User -> Employee -> Manager -> Top Manager
edit
"This is a program to manage the
vacations plans of workers."
In you company do Managers take planned vacation? Surely they do. And equally surely you are not going to build a separate application to manage that. So what you really need is this:
User -> Requester
-> Approver
Each User will be a Requester in one approval chain. (You may need special arrangements for the CEO). In addition some Users will be Approvers in one or more chains. The final approver will probably vary depending on the grade of the Requester: the CEO won't want to bother themselves with approving the vacation arrangements of the janitorial staff.
You will need some rules to enforce who can be an Approver of any given Requester's holidays. Unless you have an exceedingly flat organisation you will find you have a hierarchy of workers and managers. For instance, a Team Leader or a foreman - individuals who are in other respects "workers" rather than "managers" - may be in the chain. Also you may need to consider other aspects of the organisation. Fr instance, if the employee wishes to carry leave over to the next year that may require approval from the HR dept, somebody who normally has no managerial responsibility for the employee whatsoever.
Edit 2
Okay, so we are modelling an arbitrary set of rules rather than a realistic scenario.
Let's see. Each User fits into a single category, defined by these tasks:
an Employee can Request leave
a Manager can Approval or Reject a Leave Request
a Top Manager can Accept or Overturn an Approval or Rejection
Managers and Top Managers have no behaviours in common. Consequently, the first model is the correct one.
I would model these as actors. They are not the domain of the system, but the users of the system. Would you model a shop's inventory system with 'school-kid who wants sweets', 'school-kid's parent who wants tobacco', 'clerk' etc? Although only a store manager (actor) can give refunds without a receipt, what matters at the system level is that system recognises the store manager's key, and it's that permission token which is in the software rather than role the actor takes.
The domain of the system you describe is vacation requests and the user account, and some of the use cases mean that some of the accounts have permission to perform certain state transformations to a vacation request.
The difference in modelling User/Manager/Employee as actors and roles is that you can focus on modelling what you need to put into the system, as don't have to have hierarchies of actors - you start using abstraction at the use case and system entity levels, rather than in the actors. It's not always a bad idea to think 'how would this work in code', at least as far as asking 'why bother coding this distinction'.