I`d like to know which properties/functions must have which privileges to be used. Is there such a list?
For example, when developing code, how can I know which properties or functions will work for site members, visitors or owners?
It's not so much about properties and functions. It is really for any time you are trying to execute a bit of code that the current user would not ordinarily have permission to run. For example, say you wanted to create a subsite based on some user-provided info when the user adds an item to a list. The user doesn't have privs to explicitly create such a site on his own. In a list item event receiver you would use a RunWithElevatedPrivileges block to create this subsite. That way the site gets created as the application pool owner rather than as the logged-in user, and you avoid the security issue. Of course, you will want to be careful what you do in such a block.
Related
I'm using ApacheDS as directory server which is used in applications like Gogs (Git server like GitLab). My idea is to create groups like gogs-users and restrict the login to those group, so that only users who are member of that group are able to login. I have created a groupOfNames for this and a testuser, which is added to the gogs group.
The type of gogs-users is groupOfNames and it has an attribute member which contains the DN of my user (uid=testuser,ou=Users,DC=example,DC=com). So I'm able to see, who is a member of this group.
But I would like to see all groups where a user is a member of. When I open the testuser, I see no attribute that could tell me, that he's a member of gogs-users. I remember that the proprietary Active Directory had an attribute called memberOf whch was queryable in a filter like (&(objectClass=inetOrgPerson)(memberOf=CN=gogs-user,DC=example,DC=com)). That would be exactly what I need.
How can I get this in a free LDAP implementation? I see no way except defining a custom attribute - Which I had to maintenant per hand. That's not good, I would like to have an automated solution, that keep care of those attribute.
Things I already tried
https://stackoverflow.com/a/34502363/3276634 No changes
https://morenews.blogspot.de/2010/12/adding-active-directory-properties-to.html No changes, too
Note: I did a complete reset after each scheme import, to make sure, that my tests are not influenced by previous changes.
Here are Queries that will go either way but ONLY work for Microsoft Active Directory:
Resolves all members (including nested) Security Groups (requires at least Windows 2003 SP2):
(memberOf:1.2.840.113556.1.4.1941:=CN=gogs-user,DC=example,DC=com)
And
All Groups a User is a member of including Nested Groups
(member:1.2.840.113556.1.4.1941:=CN=UserName,CN=Users,DC=YOURDOMAIN,DC=NET))
I have a navigation bar at the top of my Xpages applications. This element is going to be shared among many Xpage apps - it will work kind of like a intranet for our Xpage apps.
I do not want to display databases links to users who do not have access to the database.
How do I determine if a user can access a db? And is this something that I should somehow cache, so it doesn't have to be loaded again and again:
You can use the Database method queryAccess(name) to get the ACL level for the individual user. You can then check for No Access and for Depositor. Here's an example that returns true if the user has access to db:
db.queryAccess(userName) != ACL.LEVEL_NOACCESS && db.queryAccess(userName) != ACL.LEVEL_DEPOSITOR
I will suggest that you cache this in a user bean for the user.
Per's suggestion is great but be aware of one limitation on queryaccess:
From the documentation:
If the name you specify is listed explicitly in the ACL, queryAccess returns the access level for that ACL entry and does not check the groups.
If the name you specify is not listed explicitly in the ACL, queryAccess checks if the name is a member of a group in the primary Address Book known to the computer on which the script is running. On a local workstation, that address book is the Personal Address Book. On a server, that address book is the Domino® Directory. If queryAccess finds the name in one or more groups, it returns the highest access level among those groups. If the name you specify is not listed in the ACL either individually or as part of a group, queryAccess returns the default access level for the ACL.
First of all - if code runs under user's privileges, you can't call queryAccess for database you can't open. To work around this you could force the code to use signer's session and get the access. But...
I recommend this: make a bean named hasAccess. About the scope:
application scope is shared among users - useless
session scope - quite fine, but in case of ACL change
you would need to restart http or wait for session timeout
view scope is recommended
request scope wont help much
Implement map interface, so you can bind it like #{hasAccess[database]} where database will be filepath, or some special key to lookup database. Implement cache and return true/false, according to user's access. How do you determine user's access is up to you, but I think the best method is to use try/catch with attempt to open that database and check it with isOpen().
In my XPages application, web users can perform a self-registration. In the registration process, a user document for the web user is created in the address book and the user is added to a group that has Editor access for the database. After executing show nlcache reset on the Domino server, the user can login to and access the application.
In ~98% of all registrations this works perfectly fine. However, sometimes new users cannot enter the application after the login because, according to the Domino server, they "are not authorized to access" the database. The login must have worked because the user id is correct. The exact same user id can also be found in the Members field of the group that has Editor access to the database. To additionally verify the user's access level, I executed NotesDatabase.queryAccess() with the user's id. It returned 0, which is the ACL default and means "No Access". Yet, there are dozens of users in the same ACL group which have absolutely no problem with accessing the database.
At the moment, we "circumvent" this problem by manually removing the user's document from the address book as well as remove him/her from the Members of the ACL group. Afterwards we ask the user the re-do the self-registration with the exact same information as before. Up to now, this second registration has always worked and the user can access the application. Yet, this is not a real solution, which is why I have to ask if anyone knows what could be the problem?
Don't create entries in the address book directly. Use the adminp process for registration. To minimize perceived delay send a validation/confirmation message the user has to click.
Comment of 12/02/2015 seems to be the correct Answer:
Check if the self-registrated user has TWO consecutives spaces in his name, (could be because trailling space too)
In group domino do a FullTrim. So we have
John<space><space>Smith
that is not in group XXX because in the members it's:
John<space>Smith.
This may have something to do with the frequency at which the views index are refreshed in the names.nsf
Since the access control is done groups in the ACL, the server will "know" which user belongs to which group only after the views index have been updated.
In a normal setting, this can take a couple of minutes.
You can test this hypothesis by forcing an index refresh, either with CTRL-MAJ-F9 from your Notes client (warning, can take very long depending on network and number of entries in the names.nsf) or with the command
load updall -v names.nsf
... or by having the users wait a little while and try again 5min later.
Ok, first a question. If you let the user wait a couple of minutes will the access then work? I.e. is it a refresh/caching problem - or an inconsistency in the way you add the user to the group?
I assume that the format of the user name is correct as it works in most cases (i.e. fully hierarchical name)... Is there anything "special" about the names that do not work?
I do a similar thing (and has done several times) - although with some differences :-)
I typically use Directory Assistance to include my database with a "($Users)" view. When I update anything in this view I do a view.refresh() on the view (using Java). I typically do not use groups in these type of applications (either not applicable - or I use OU's or roles for specific users). I am not sure how the group membership is calculated - but I guess you could try to locate the relevant view (though none of them seemed obvious when I looked) - and do a refresh on it.
/John
We plan to implement a company-internal portal with Liferay 6.2. Since many of the team members are not within the company's network, the access has to be allowed from the internet.
Now I see a big problem with the Guest role, since it 1) can access Guest-viewable content without login and 2) this is the default selection when for example uploading a document.
What I really need, is that only the login page is generally viewable, but all other sites and content is only visible to logged-in users, without the need to explicitely assign the permissions for each item correctly.
So the question is, can I prevent the guest role to access anything beyond the login page, so to say eliminate it from everything within the portal?
Update:
It was proposed to use only private pages. While this might work, it implies as far as I know, that each user has to be member of the site. But then it's no longer possible to have a site structure with different users participating in different sites and still be able to view public infomation (meaning public for all logged-in users) - or am I wrong?
Update 2:
I agree to a solution where one has to prevent the assignments to the guest role programmatically, via hook or via deeper changes in liferay. Yet, I like to double-check that administrative and think of a periodic database job or program using the API which check for relations to the guest role which came in around the hook or by wrong permission settings of a user and delete them again. How could that be done?
When a document is uploaded through a private page, the permissions actually default to be not accessible to "Guest". This is guaranteed easiest if you don't have any public pages.
Also, you can access the API and change the default permissions once a document gets uploaded (no need to override core Liferay functionality like defaults): Just write a service hook that overrides the upload of a document with a version that sets the permissions you want right after a document has been uploaded. This will catch all other upload attempts, e.g. through services, Webdav etc.
Edit (after your comment): Added the link to Dev Guide. The actual use of the API is a bit too much to update this answer with on the fly. You might want to look at old examples like sevencogs (part 2) to get used to the actual API, but DevGuide will describe how to write the plugin in the first place.
You could still use the public pages etc. and disable the guest's VIEW permission on every element but the login page and it's resources.
Now, as you have already noticed, the fact that, by default, whenever creating any content the Guest gets the VIEW permission is a substantial problem.
I'd suggest to simply override the <guest-defaults> values in Liferay's core portlets' resource permission files (the ones in ROOT/WEB-INF/classes/resource-actions/) to remove these default values. If it's not clear to you on how to do it, see, e.g., this forum topic: https://www.liferay.com/community/forums/-/message_boards/message/486154 .
All you need to do is delete all public pages. Every page that you create should be private. Don't worry about login page, reset password and self-registration (if allowed), by default they are public.
Hope this helps.
I'm trying to come up with a good way to do authentication and authorization. Here is what I have. Comments are welcome and what I am hoping for.
I have php on a mac server.
I have Microsoft AD for user accounts.
I am using LDAP to query the AD when the user logs in to the Intranet.
My design question concerns what to do with that AD information. It was suggested by a co-worker to use a naming convention in the AD to avoid an intermediary database. For example, I have a webpage, personnel_payroll.php. I get the url and with the URL and the AD user query the AD for the group personnel_payroll. If the logged in user is in that group they are authorized to view the page. I would have to have a group for every page or at least user domain users for the generic authentication.
It gets more tricky with controls on a page. For example, say there is a button on a page or a grid, only managers can see this. I would need personnel_payroll_myButton as a group in my AD. If the user is in that group, they get the button. I could have many groups if a page had several different levels of authorizations.
Yes, my AD would be huge, but if I don't do this something else will, whether it is MySQL (or some other db), a text file, the httpd.conf, etc.
I would have a generic php funciton IsAuthorized for the various items that passes the url or control name and the authenticated user.
Is there something inherently wrong with using a naming convention for security like this and using the AD as that repository? I have to keep is somewhere. Why not AD?
Thank you for comments.
EDIT: Do you think this scheme would result in super slow pages because of the LDAP calls?
EDIT: I cannot be the first person to ever think of this. Any thoughts on this are appreciated.
EDIT: Thank you to everyone. I am sorry that I could not give you all more points for answering. I had to choose one.
I wonder if there might be a different way of expressing and storing the permissions that would work more cleanly and efficiently.
Most applications are divided into functional areas or roles, and permissions are assigned based on those [broad] areas, as opposed to per-page permissions. So for example, you might have permissions like:
UseApplication
CreateUser
ResetOtherUserPassword
ViewPayrollData
ModifyPayrollData
Or with roles, you could have:
ApplicationUser
ApplicationAdmin
PayrollAdmin
It is likely that the roles (and possibly the per-functionality permissions) may already map to data stored in Active Directory, such as existing AD Groups/Roles. And if it doesn't, it will still be a lot easier to maintain than per-page permissions. The permissions can be maintained as user groups (a user is either in a group, so has the permission, or isn't), or alternately as a custom attribute:
dn: cn=John Doe,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: webAppUser
cn: John Doe
givenName: John
...
myApplicationPermission: UseApplication
myApplicationPermission: ViewPayrollData
This has the advantage that the schema changes are minimal. If you use groups, AD (and every other LDAP server on the planet) already has that functionality, and if you use a custom attribute like this, only a single attribute (and presumably an objectClass, webAppUser in the above example) would need to be added.
Next, you need to decide how to use the data. One possibility would be to check the user's permissions (find out what groups they are in, or what permissions they have been granted) when they log in and store them on the webserver-side in their session. This has the problem that permissions changes only take effect at user-login time and not immediately. If you don't expect permissions to change very often (or while a user is concurrently using the system) this is probably a reasonable way to go. There are variations of this, such as reloading the user's permissions after a certain amount of time has elapsed.
Another possibility, but with more serious (negative) performance implications is to check permissions as needed. In this case you end up hitting the AD server more frequently, causing increased load (both on the web server and AD server), increased network traffic, and higher latency/request times. But you can be sure that the permissions are always up-to-date.
If you still think that it would be useful to have individual pages and buttons names as part of the permissions check, you could have a global "map" of page/button => permission, and do all of your permissions lookups through that. Something (completely un-tested, and mostly pseudocode):
$permMap = array(
"personnel_payroll" => "ViewPayroll",
"personnel_payroll_myButton" => "EditPayroll",
...
);
function check_permission($elementName) {
$permissionName = $permMap[$elementName];
return isUserInLdapGroup($user,$permissionName);
}
The idea of using AD for permissions isn't flawed unless your AD can't scale. If using a local database would be faster/more reliable/flexible, then use that.
Using the naming convention for finding the correct security roles is pretty fragile, though. You will inevitably run into situations where your natural mapping doesn't correspond to the real mapping. Silly things like you want the URL to be "finbiz", but its already in AD as "business-finance" - do you duplicate the group and keep them synchronized, or do you do the remapping within your application...? Sometimes its as simple as "FinBiz" vs "finbiz".
IMO, its best to avoid that sort of problem to begin with, e.g, use group "185" instead of "finbiz" or "business-finance", or some other key that you have more control over.
Regardless of how your getting your permissions, if end up having to cache it, you'll have to deal with stale cache data.
If you have to use ldap, it would make more sense to create a permissions ou (or whatever the AD equivalent of "schema" is) so that you can map arbitrary entities to those permissions. Cache that data, and you should ok.
Edit:
Part of the question seems to be to avoid an intermediary database - why not make the intermediary the primary? Sync the local permissions database to AD regularly (via a hook or polling), and you can avoid two important issues 1) fragile naming convention, 2) external datasource going down.
You will have very slow pages this way (it sounds to me like you'll be re-querying AD LDAP every time a user navigates to figure out what he can do), unless you implement caching of some kind, but then you may run into volatile permission issues (revoked/added permissions on AD while you didn't know about it).
I'd keep permissions and such separate and not use AD as the repository to manage your application specific authorization. Instead use a separate storage provider which will be much easier to maintain and extend as necessary.
Is there something inherently wrong with using a naming convention for security like
this and using the AD as that repository? I have to keep is somewhere. Why not AD?
Logically, using groups for authorization in LDAP/AD is just what it was designed for. An LDAP query of a specific user should be reasonably fast.
In practice, AD can be very unpredictable about how long data changes take to replicate between servers. If someday your app ends up in a big forest with domain controllers distributed all over the continent, you will really regret putting fine-grained data into there. Seriously, it can take an hour for that stuff to replicate for some customers I've worked with. Mysterious situations arise where things magically start working after servers are rebooted and the like.
It's fine to use a directory for 'myapp-users', 'managers', 'payroll' type groups. Try to avoid repeated and wasteful LDAP lookups.
If you were on Windows, one possibility is to create a little file on the local disk for each authorized item. This gives you 'securable objects'. Your app can then impersonate the user and try to open the file. This leverages MS's big investment over the years on optimizing this stuff. Maybe you can do this on the Mac somehow.
Also, check out Apache's mod_auth_ldap. It is said to support "Complex authorization policies can be implemented by representing the policy with LDAP filters."
I don't know what your app does that it doesn't use some kind of database for stuff. Good for you for not taking the easy way out! Here's where a flat text file with JSON can go a long way.
It seems what you're describing is an Access Control List (ACL) to accompany authentication, since you're going beyond 'groups' to specific actions within that group. To create an ACL without a database separate from your authentication means, I'd suggest taking a look at the Zend Framework for PHP, specifically the ACL module.
In your AD settings, assign users to groups (you mention "managers", you'd likely have "users", "administrators", possibly some department-specific groups, and a generic "public" if a user is not part of a group). The Zend ACL module allows you to define "resources" (correlating to page names in your example), and 'actions' within those resources. These are then saved in the session as an object that can be referred to to determine if a user has access. For example:
<?php
$acl = new Zend_Acl();
$acl->addRole(new Zend_Acl_Role('public'));
$acl->addRole(new Zend_Acl_Role('users'));
$acl->addRole(new Zend_Acl_Role('manager'), 'users');
$acl->add(new Zend_Acl_Resource('about')); // Public 'about us' page
$acl->add(new Zend_Acl_Resource('personnel_payroll')); // Payroll page from original post
$acl->allow('users', null, 'view'); // 'users' can view all pages
$acl->allow('public', 'about', 'view'); // 'public' can only view about page
$acl->allow('managers', 'personnel_payroll', 'edit'); // 'managers' can edit the personnel_payroll page, and can view it since they inherit permissions of the 'users' group
// Query the ACL:
echo $acl->isAllowed('public', 'personnel_payroll', 'view') ? "allowed" : "denied"; // denied
echo $acl->isAllowed('users', 'personnel_payroll', 'view') ? "allowed" : "denied"; // allowed
echo $acl->isAllowed('users', 'personnel_payroll', 'edit') ? "allowed" : "denied"; // denied
echo $acl->isAllowed('managers', 'personnel_payroll', 'edit') ? "allowed" : "denied"; // allowed
?>
The benefit to separating the ACL from the AD would be that as the code changes (and what "actions" are possible within the various areas), granting access to them is in the same location, rather than having to administrate the AD server to make the change. And you're using an existing (stable) framework so you don't have to reinvent the wheel with your own isAuthorized function.