I am currently setting up a small server with several applications. Since no Active Directory etc is planned, but I do need a centralized user administration, I decided for LDAP since all applications are capable of authenticating against it.
I have already set up a domain "dc=example,dc=lan". It has two organizational Units. Groups and Users. My plan was, to create a posixGroup for every application, so that a user can be added to each group (if he/she was allowed to use this application).
The structure would then be (example):
for each group
cn=ejabberd,ou=groups,dc=example,dc=lan
where cn=ejabberd is of type "posixGroup"
and for users
cn=user1,ou=users,dc=example,dc=lan
where cn=user1 is of type "posixAccount"
Some, but not all, applications expect the "mail" attribute as login name. Some don't.
My problem is, that searching for users in ou=users is easy as 1,2,3 - searching in "cn=ejabberd,ou=groups,dc=example,dc=lan" is sheer driving me crazy since the users are not a "child" to this group but a "memberuid" attribute.
I have tried different filters and thought about another setup.. Just cannot think of anything different making sense right now.
Am I running down the wrong way, or maybe just blind to what's right in front of me?
I'd be glad for any finger pointing out a direction.
So here is, how I did it:
I created the following structure.
+dc=example,dc=com
+ou=groups
| +employees (PosixGroup)
| +service1 (GroupOfNames)
| +service2 (GroupOfNames)
+ou=users
| +user1 (User Account)
| +user2 (User Account)
etc..
Groups like "service1" and "service2" are of type "GroupOfNames". Furthermore I had to install the "memberOf"-Overlay so I could search for this exact attribute of a user.
This now gives me the possibility to tell each service to use a search filter that returns only the members of one special group, which will be granted access. For instance, ejabberd will use this filter:
"(&(objectClass=inetOrgPerson)(memberof=cn=ejabberd,ou=groups,dc=example,dc=com))"
Found these informations on the following website. Just take care to set the filter case sensitive! "memberOf" will not return any results, since the overlay in this example uses "memberof".
http://www.schenkels.nl/2013/03/how-to-setup-openldap-with-memberof-overlay-ubuntu-12-04/
I suggest you're on the wrong track. You don't want to authenticate by application, you just want to define overall roles that users can be in. The applications can then be defined to require certain role(s) per application funtion, web page, etc. As a limiting case, an application can be a role, but if you set out to define it that way you're overly limiting yourself.
To answer your immediate problem, you only have to search under the ou=Groups item for posixGroups which have memberUID={0} where {0} is the DN of the user. In other words the search filter is
(&(objectClass=posixGroup)(memberUID={0}))
Iterating those search results then gives you the DNs of all the groups of which he is a member.
Related
I have setup my web api to use policy based authorization. I can have permissions like invoice:list, invoice:edit, invoice:delete, order:list, order:edit and so on.
Now, I need to return different sets of data depending on the user that is logged in. For example an user can retrieve all invoices (sales manager for example) and others just the ones created by them.
Would it be a good way to do it, add a bit more information to the claim like -> inovice:list:all, invoice:list:own, etc...? And add differnt filters to the final query depending on the "all" or "own" part?
What other alternatives can be implemented to solve this problem?
Cheers.
Currently I'm building a web app. So far I only have regular users. However, due to some requirements I need to have special admin accounts for the app administrators. I'm wondering now how these are usually implemented. The requirement is, that they use the same login mask as regular users and behave the same except for the additional capabilities. To differentiate I could put an admin flag into the users' profile or put the admins into a separate table in my DB. Maybe the the second option scales better for potential additional user groups. Also, how could these admins be signed up? I don't want to use predefined usernames I check against in the login handler. I know the question is rather general. I'm just looking for some directions.
Since you didn't give information about the platform(s) you are using, I can only give theoretical answer. While a simple "isadmin checkbox" will do the job for only separating normal users and admins, but if you will need another user type such as "power users" etc. you will keep adding new columns to your table, which is not ideal. Basically you can use a "Role Based" or a "Permission" based approach. In Role based, as the name implies, you assign each user a role and give access to specific resources depending on the role. In the "Permissions" approach you define for each user the permissions they have (resources to access, actions they can perform). Also you could combine these two approaches, where you assign each user his role and define permissions for each role.
Let's say I have a table of food items to bring to a lunch on a very simple web page. I don't want there to be login, but I would like there to be some smartness to my app.
Let's say a user puts in a food item. Other than a login, couldn't I use the IP address to do things like: only the user that created the record at same IP address can edit this record. Something like that.
I was thinking one more step toward a login, have a single text box where a user can put initials.
This way first person to suggest bring an item can be happy to know their todo for the lunch is done and can't be "overwritten"
That's it!
Pros and cons, welcomed!
This is more of a helper app than a formal thing, like to help around the office of local users.
Authentication and Authorization are separate functions, and I'm drawing the distinction here for a reason.
Authentication is the process of positively identifying a user, so you know who they are.
Authorization is the process of allowing or preventing that user from accessing parts of the application.
IP addresses can be used to partially identify users, but as #Dai pointed out in his comment, it has problems. Even using a Mac address is problematic since some people know how to spoof Mac addresses. If you can use someone else's authentication service, you can authorize them yourself.
Once you have positively identified a user, you can track them using a randomly generated ID that is good for a session. It is possible to use a cookie to track that ID. If that ID is associated with a Role you can authorize based on that role.
OK, so it's a badly phrased question. But it's hard to explain in a single line.
I've tried to read the Shibboleth documentation and being a newbie got out of my depth fairly rapidly. I don't really want to spend days understanding it if an expert can take half a minute to say "no chance, that won't work".
I have many groups of users, lets say (for now) that groups are different companies.
What I'd like to do is only allow users to see some fields from other companies.
For example I'm Alice in Company A and I can see that Bob in Company B has an email address bob#b.com. He can see that I'm alice#a.com
However everyone else in Company B can see that Bob has a last name and a phone number etc.
And everyone else in Company A can see my details.
To make this more complicated, lets say that Bob and I become friends and decide we want to share our information then we create a "transient" group "alice&bob". Because we are both members of that group, we can both see each others full details. (But nobody else in A can see Bob's details unless they are also friends and vice versa)
I can sort all that out in application code by querying all attributes and relationships and only showing what's relevant but for extra security I'd like to limit the disclosure of information at source.
I think I need to use attribute filters but not sure if they are able to give me this level of control. With this flexibility of being able to form relationships, will I need to build filter files on the fly and then end up with thousands of filters that Shibboleth starts to choke on because the logic is so long.
Something like the "is requester in group" filter rule :
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeRequesterInEntityGroup
The answer above is quite good, but i believe that non shibboleth users will find it confusing.
The quick answer is You really don't want to do it this way, it may be possible to do but for 100% there are better tools to do it.
Ok, full version now (sorry for being too obvious i some places).
In shibboleth architecture we can distinguish two main components.
Identity Provider IdP- which holds information about users from specific organizations.
Service Provider SP - which are generally some service or protected resource, for which we can define some access rules
In your example credentials for Alice and Bob could be stored in different IdP, because they are member of different organizations/companies, or (which isn't exactly matching the whole pattern) you can have one IdP for all users, and "company" is just one of user attributes. IdP doesn't provide you any kind of api that will give you opportunity to access users attributes for any user, apart from the one that is being authenticated.
On the other hand you have your SP, which hold some super secret resources, for which you can define policies. And in which you would like to define polices for user information.
And here lays the problem, on SP side you don't have access to whole users database, that's the way Shibboleth works. You can of course treat all users information as a resource in your SP, but why in the hell would you like to use Shibboleth if you have clear access to all users credentials on you application side?
If you store all users information on you service side I believe that any well designed relational database with some kind of authentication for your service will be better than shibboleth for this job.
Hope that helped.
This is not a job for Shibboleth or for most SAML/SSO providers, for that matter. The attribute filtering you speak of is used for filtering those attributes between the IdP and SP ... which is basically saying : let service provider or "application" B see the following attributes from IdP A.
Once you transmit the attributes to the SP on the other end, Shibboleth does not (and indeed cannot) provide you with a mechanism to prevent users of application B from seeing any data that you present to them ... in fact, they really shouldnt be able to see any data transmitted by the IdP unless you are exposing it in someway via your application.
I'm working on a site, which will have several modules that either fully available to certain users, semi available to other users, and unavailable to the rest.
For example:
An 'employee' is able to respond to the customer support tickets assigned to him.
A 'Manager' is able to manage all employees and support tickets in his team, including viewing the tickets of a specific employee.
An 'Admin' is able to manage all managers, employees, and tickets in all teams, as well as some other core functionality.
In addition, on some pages there will be some additional fields shown if the current user is an admin or manager. (E.g links to delete/flag things). These won't be shown to employees.
I want to create one 'Permissions' model which will handle the logic for:
Determining if a user can access the current page or not.
Determining whether a particular part of a page should be displayed or not. (E.g special links for editing/deleting to be shown to admins and managers only).
I need some recommendations/advice for designing this class, particularly what methods it should have in order to accomplish the 2nd requirement.
The way I have approached this problem when it has come up is to give each action that can be taken or piece of information that can be shown it's own Permission. Each User then has a collection of Permissions. From this, you can add other layers of structure to help manage the huge number of permissions that will exist, such as hierarchies or categories of permissions.
Once that is in place, you can either have the various parts ask the User if they have the needed permission(s), or you can have a PermissionManager take a User and a set of Permissions and determine if the given user has the needed Permissions. Either way will work fine, but which one you choose has an impact on dependencies and the architecture of your system.
The PermissionManager approach has the advantage that your application pieces don't need to depend on a User, so you could use a different PermissionManager that always returns False if no permissions is appropriate, or True if all permissions is appropriate.
For simple situations, this approach can be overkill, and it often seems like it is at first, but I've gone the route of using basic hierarchical or coarse-grained Roles and fond that virtually every system I've worked on quickly got too complicated for most vanilla, pre-built Roles-based permission systems.
My approach to this problem from database point of view would be to have a user table which holds the list of users, a role table for the list of roles, e.g.: employee, manager, admin; and permission table which stores all of the values of every action/feature available in the system and its permission for a specific role, e.g.: say for admin, the values for actions/features like create, edit, delete, view are all true. The relationships can be seen below whereas (N) ---- (N) is a many-to-many relationship.
Users (N) ------- (N) Roles (N) -------- (N) Permission
My impression is that you would require to make use of roles e.g. employee, Manager, and Admin. So a roles table with these would do. Then for the particular actions/permisions you would have to make use of branching logic i.e. for example for the employee you will have
if User.IsInRole("employee")
// insert logic to deal with customer support tickets
else if User.IsInRole("manager")
// insert logic to deal with manager responsibilities
and finally logic to deal with admin responsibilities
So you need both the users table and the roles table to achieve this.
Hope it helps