Filter users in OpenLDAP ACL by attribute value - acl

I want to give access to users who have attribute with certain value.
Let's say I have "ou=protected,dc=example,dc=com" directory and I want it to be writable by any user with canAccessProtected attribute set to TRUE.
Something like
access to dn.subtree="ou=protected,dc=example,dc=com"
by users/canAccessProtected="TRUE" write
I've checked documentation and was unable to find a way, although I haven't grasped sets and few other things.
Is it possible to manage user access by attribute value? If yes, then how?

Create a dynamic group like:
dn:cn=protectedGroup,ou=groups,dc=example,dc=com
objectClass:top
objectClass:groupOfURLs
cn:protectedGroup
memberURL: ldap:///ou=users,dc=example,dc=com??sub?(canAccessProtected=TRUE)
Enable dynlist in your slapd.conf like:
overlay dynlist
dynlist-attrset groupOfURLs memberURL member
Grant write access to the members of that group:
access to dn.subtree="ou=protected,dc=example,dc=com"
by set="[cn=protectedGroup,ou=groups,dc=example,dc=com]/member & user" write
Add necessary ACL rules as you see fit.

Related

How to efficiently render content based on user permission? (Using permission based access control)

Rendering based on roles is a common thing, you have the admin, moderator and user and render it accordingly. However, how can I render it based on general rules? This structure below may help:
---Platform (platform)
-----Manage User (permissionGroup)
---------Delete (permission)
---------Update
---------Create
---------Update
I could render every permission inside the platform like this, but the UX/UI wouldn't be good, so the wanted approach would be something like:
---Platform (platform)
-----Manage User(permissionGroup)
Then inside the manage user I could list (permission) them, and for each, buttons called Update and Delete would appear.
Simplified tables below:
platform(
id
icon (for automatic rendering purposes)
name (for automatic rendering purposes)
);
permissionGroup(
id,
icon (for automatic rendering purposes)
name (for automatic rendering purposes)
route
platformID
);
permission(
id
permissionGroupID
name
isActive
);
userPermission(
id
permissionID
userID
);
What is the best way I could render the content based on these permission rules?
After some googling I found this lib, which looks promising. In nutshell, it basically lets you define all the permissions for current role in single file without code duplication. It also has a vue integration.
you can try CASL. check below .
https://github.com/stalniy/casl/blob/master/packages/casl-react/README.md

How do I change a user's Email address in MediaWiki

With access sysop and database access how do I change the Email address associated with a user?
The user table in the database has everything encoded as BLOBs. If I can decode and encode those values presumably I can just update user.user_email.
UPDATE user SET user_email='foo#bar.com' WHERE user_id=... should just work. However, if you need to also set the confirmed flag, see instructions here (replace the mwscript line with php maintenance/eval.php). If you need to set their email only so that they could reset their password, see https://www.mediawiki.org/wiki/Manual:Resetting_passwords
You can get a current list of users and emails like this (i.e. decode):
SELECT Cast(user_name AS CHAR), Cast(User_Email AS CHAR) FROM user;
MaxSem's answer did not work for me, but here is a MediaWiki maintenance script (introduced in v1.27) that'll do the trick: https://www.mediawiki.org/wiki/Manual:ResetUserEmail.php
Go to the base directory of your wiki, and type something like this:
php maintenance/resetUserEmail.php uuuu new#email.address
to change user uuuu's email address to new#email.address. By default, this will change the user's password so that the user has to reset it, which can usually be done on the wiki website. You might need to add user name and password for database access, e.g.:
php maintenance/resetUserEmail.php --dbuser myuser --dbpass wordpass uuuu new#email.address

Can user change ID of an element?

So as the title says I'm curious, can user change the ID of an element through browser? I have a list of inputs - checkboxes, when you click on one of them ajax takes ID of that element and uses it to get data from database, so basically what I'm thinking is that if it is somehow possible to change the ID of the element my database wouldn't be secured. If that's possible, how I should protect it?
Okay, So I get the idea that it wouldn't be secured, If I'd use this way:
<?php
$mysqli = new mysqli("host", "user", "password", "database");
$usuario = $mysqli->real_escape_string($_POST["usuario"]);
$clave = $mysqli->real_escape_string($_POST["clave"]);
$sql=' SELECT * FROM usuarios
WHERE username="'.$usuario.'"
AND pass="'.$clave.'"
';
$mysqli->query($sql);
$mysqli->close();
?>
would it be enough, or there aren't actually safe enough way to protect data?
You are correct that this would be a security hole. The ID attributes could indeed be changed via the browser console.
Yes, they can change it or just make while request faked and you won't tell the difference. Rule of thumb here is NEVER trust any data that comes from user. It means - always validate, sanitize data on server-side, and always assume data that comes in request are there to fool/trick/hack you.
Yes. The user can do anything they like to the DOM once it is in their browser.
They can also execute any JS they like there.
You're worrying about the problem in the wrong place though. Your control ends at the edge of the webserver. Clients can make any HTTP request they like to it and include any id value they want. You need to address security there and not in the browser.
If you want to secure your database then you need to either allow no HTTP request to lead to the secret data being released / changed or you need to write server side rules that limit which HTTP requests can change them.
Typically this would involve Knowing Who The Request Comes From (Authentication) and Knowing Who Can Access Which IDs (Authorization).
A simple approach would be to keep a database that has a users table (including hashed passwords), a "things" table, and an ownership table (which has a column of user ids and a column of thing ids). If the request doesn't include a username and password you can cross reference from the thing id across the ownership table - return an error message instead of what was asked for.

Hide toolbox for all users except admin and bureaucrat in MediaWiki

In skins/Vector.php I can hide toolbox from logged out user
by adding
global $wgUser;
then
case 'TOOLBOX':
if ( $wgUser->isLoggedIn() ) {
$this->renderPortal( 'tb', $this->getToolbox(), 'toolbox', 'SkinTemplateToolboxEnd' );
}
but User::isSysop() and similar are deprecated. It is recommended to use $user->isAllowed instead to specify a right, but how do I use this to specify the admin and bureaucrat group? Should I use some other function?
MediaWiki 1.22.2
PHP 5.3.6-13ubuntu3.10 (apache2handler)
MySQL 5.1.69-0ubuntu0.11.10.1-log
User::isAllowed() asks for a permission to do something, not for a user group (which leaves it up to the wiki admin to assign different rights to different user groups). In your case, you would want a new user permission, “see-toolbar”,or something like that, that you assign to e.g. the sysop user group in LocalSettings.php:
$wgGroupPermissions['sysop']['see-toolbar'] = true;
Your extension will also have to add the right to the list of available rights: $wgAvailableRights[] = 'see-toolbar';
Finally, you will ask for the permission like this:
if ( $user->isAllowed('see-toolbar') ) {
print toolbar here
}
More info on how to set user rights: https://www.mediawiki.org/wiki/Manual:User_rightser
Other extensions adding user rights: https://www.mediawiki.org/wiki/Category:Extensions_which_add_rights
Be aware that any user will still be able to bypass this restriction in a number of ways, e.g. by switching skin in their settings (or by appending ?useskin=skinname in the url). You probably want to make sure that sidebar caching is switched off too (it is off by default).

How to suggest alternative usernames during signup in case username is unavailable?

How can I suggest a list of alternate usernames in case user has selected an invalid or existing username?
The suggestions must be somewhat related. Do I need to use a dictionary of possible usernames?
It depends entirely on what you consider "related". It's hard to define such a meaning for usernames, as they often aren't normal English words. You might wish to create a unique username by appending a random stream of numbers, or by changing some of the letters to numbers ('e' to '3' etc). If you will update your question with what you mean by 'relevant' I will try and tackle that specific issue.
Bad idea. Giving away related usernames allows a skillful attacker to deduce which usernames are in use.
IE if I try and register 'RandomUser' and the system suggests using on of:
RandomUser1
RandomUser2
RandomUser3
RandomUser5
Then I can reasonably surmise that RandomUser4 is a valid username.
Look a this:
http://www.onesoft.dk/post/2007/07/ASPNET-AJAX-username-availability-with-suggestions.aspx
Its build using Ajax & JSON. I'm sure you will be able to adapt it to your technology.
Just add more info to the user name that the user seleced. If you colected also info like birthday, you can add to it the year:
user -> user1985
Or if you're getting a first name:
user -> jose_user
Don't use "automatic" information, because it would make it easy for attackers to deduce valid user names.