Changes between Version 1 and Version 2 of EchoSystem

Timestamp:

07/11/12 14:58:21 (12 years ago)

Author:

dabantz@…

Comment:

--

EchoSystem

@@ -33 +33 @@
 === Practical Usage ===
 Even given the field definitions above, it can sometimes be hard to determine what their actual values should be in order to secure access to the right set of accounts. The constraints are usually simple: one might have a large pool of user accounts, but only want users belonging to a certain group to have access. When thought of this way, configuration needn't be very complex.
+
 To start with, it is important to realize that when dealing with LDAP directories, there are two different ways that "groups," or collections of users can be identified. One way is to use containers, but this is limiting since users are unique objects -- and a user can only exist in one container at a time. The best we can do with containers is specify which container holds the pool of users we want to select from. These are simple, "vertical" relationships.
+
 The other way is to use attributes. In Active Directory, for example, a user might have many "memberOf" attributes, each one having a value that matches the distinguished name of some group anywhere else in the tree. This is the most common way group membership is assigned. One user can therefore participate in many different groups, any of which could be useful for filtering against. These are one-to-many "horizontal" relationships and can even involve complex inheritance structures such as where one group is a member of another, larger, group of groups.
+
 Most often, somewhere in the LDAP directory (or Active Directory) schema, there is a container within which most or all login accounts of a certain type are stored. These might represent the user names of all students, students of a specific class, or all faculty users, for example. Sometimes, these are the groups one might want to grant access -- anyone with a valid user account, perhaps. In this case, the container full of users is actually what we would call
 the Base User DN, and this distinguished name would be used to select that container in the ESS configuration.
+
 In other cases, these broad categories aren't nearly refined enough to limit access to the right subset of accounts -- such as students in a certain course or program. You still need the same Base User DN as in the previous example to tell the ESS where all the candidate accounts are, but then you'd need an additional parameter to filter out the ones that shouldn't be allowed in. This is when you would use attributes. The easiest way in many common situations is to put the group membership attribute in the Extra User Attribute Name field (it might even match the group membership attribute exactly), and the DN of a group in theRequired Extra User Attribute Value field. Any user account that meets that membership requirement will be granted access; all others (even if they're in the same Base User DN) will be denied.
+
 Of course, you can use up to three tree search definitions with AND or OR operators to combine filters so that multiple ranges of users -- or even a subset of users located only where multiple groups overlap -- are given access.
 === Deploying the Security Module ===