I have configured request tracker4 to be an interdepartmental helpdesk solution. The current setup is that users will login to RT using LDAP. Once logged in there account is automatically created. However, their account is created with no privileges.
To fix this I have been having to go to Tools-->Configuration-->Select then put in the users DN name and clicking add I then have to check the box "Let this user be granted rights (Privileged)" I have also tried setting Set($AutoCreate, Privileged); but no luck.
I looked at the user accounts in the sqlite database and noticed that when new user logs in they are indeed created in the database. But with no privileges.
709|tuser3|*NO-PASSWORD*|||||||tuser3|||||||tuser3||tuser3|||||||||||||1|2013-03-08 13:47:38|1|2013-03-08 13:47:38
791|Mayra|*NO-PASSWORD*||||Mayra#**************||Main Office|Mayra Hernandez|||||||Mayra||Mayra||**************|||||||||||1|2013-04-03 21:46:36|1|2013-04-03 21:46:36
797|sdrakeford|*NO-PASSWORD*||Autocreated when added as a watcher||sdrakeford#**************|||Sophia C. Drakeford|||||||sdrakeford||sdrakeford|||||||||||||1|2013-04-04 13:18:58|1|2013-04-04 13:18:58
827|Robert.Troy|*NO-PASSWORD*||||Robert.Troy#*******************||Main Office|Robert Troy|||||||Robert.Troy||Robert.Troy||***************|||||||||||1|2013-04-04 16:11:58|1|2013-04-04 16:11:59
Am I missing something, because usually these things are quite obvious.
The $AutoCreate option takes a hashref with all of the default options you want to pass to the User Create method. Try something like:
Set($AutoCreate, {
Privileged => 1
});
(As an aside, it's generally not recommended to run a production instance on sqlite. You might want to consider converting to MySQL or Postgres.)
Related
I have keycloak on docker (v20.0.2) and as you know some versions change some or good part of the UI, so is hard to follow tutorials around the web...
I am trying to follow this particular tuto
https://developers.redhat.com/blog/2020/11/24/authentication-and-authorization-using-the-keycloak-rest-api#keycloak_sso_demo
that seems the more updated. My keycloak is actually behind traeffic and thomseddon/traeffic-fordward-auth with a docker-compose file (but the connection through traeffic is good and I have acces to admin UI)
So on step 10 of the tutorial things change for me, I have to look for that particular view inside:
Click on lateral menu Client Scope
Click on button Create client scope
Give a name to the scope, and click on Tab Mapper
All mappers are predefined... so there is no "New mapper" don't understand this bit
then just follow the tuto
With that series of steps I get an error when retriving the token...
https://keycloak:8443/realms/education/protocol/openid-connect/token
enter image description here
(this are fake local data from the realm I created for testing)
that responds with a or something similar I have also tried to change the grant_type to password, and the same happens can not query the token....
{
"error": "invalid_client",
"error_description": "Invalid client or Invalid client credentials"
}
But if I do not link a user with an scope/role as in the tuto suggest then I get the token, but of course I want to use the role or scope to limit who can see which endpoint and who can not
Any step that I'm missing from this update, do you have the same error?
Thank you in advance
I have tried to run it with different combinations of options to see if there is a toggle that actually allows me to fetch the token
Also with different types of grant_type
I will build an API in Python (I don't know Java and prefer Json instead of XML) that connect to this keycloak to allow users or not based on their scope/role/permission or something
I need to be able to block user so if user Student try to access an url from another Student he get blocked that url. So is based on the role or scope or I don't know which is prefered or easer to accomplish, the mission is to block users or not based on a factor that could be used for this in keycloak.
Well I thought I had resolved the issues I had with the owner of a Project in Cloud Storage.
I was able to add my main email as owner and was able to access IAM ... and the 3rd party backup program worked.
Then I had the not so bright idea to remove the other owner ... now backup will not work because it was set to use the deleted owner for access (which is still a surprise to me).
So I went in to the IAM and added the owner back with the same email, quickbooksrus#gmail.com ...
However even though the email is correct when I save, it changes to quickbooks.rus#gmail.com in the permissions list, and because of this I never get the activation email ...
Why does this keep changing ? Because I deleted it in the first place ?
Thanks
I was able to figure this out, but it was simply the old email that I never used had a typo in it and was misspelled ... didn't notice it ...
No issues now ... Thank you to the Google Billing Support ...
We are trying to get this working in JBoss EAP 6.2 but for the moment we haven't been able to find the reason why it is failing.
In our application, super users are able to decide which role they want to use after login in the application. So first the user will have a role and then we want to change it. For this we are doing the following:
Subject sub = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
for (Principal p : sub.getPrincipals()) {
if ("Roles".equals(p.getName())) {
SimpleGroup group = (SimpleGroup) p;
group.removeMember(new SimplePrincipal(CONSTANT_SUPER_USER));
group.addMember(new SimplePrincipal(authorizationRole));
}
}
This is actually changing the role in the Subject. But afterwards when the authorization is being checked we get the following in the server's log:
[org.apache.catalina.authenticator] (http-/0.0.0.0:8080-11) We have cached auth type LOGIN for principal GenericPrincipal[userName(superuser,)]
As you can see, it is still getting the old value after modifying it.
We are using our own class extending SimplePrincipal. Checking the content of Faces.getRequest() we have seen that the request contains an userPrincipal of type JBossGenericPrincipal and inside it, it contains our extended SimplePrincipal. Checking both of them we have seen that:
JBossGenericPrincipal.roles contains superuser
JBossGenericPrincipal.subject.principals contains the modified SimpleGroup with the new authorization role
Just for your information, we had this working on Wildfly first and it worked perfectly, but we had to change to JBoss and found that this wasn't working properly. So we think it has to be something related to this specific JBoss version.
Has someone faced this problem? Any idea why this might be failing? I guess we need to put the correct role in JBossGenericPrincipal.roles somehow, but... how?
Any help is appreciated. Thanks!
Seems Red Hat doesn't recommend changing the roles after the authentication has been done. So the only solution was to logout and re-login the user with the new role.
I am working with GWT / RequestFactory and a set of customer requirements regarding permissions. Let me explain a basic example:
Every user is assigned to a company. Every user should be able to edit company's core data - but only e.g contact information, website etc. Security-relevant ones like BIC/SWIFT, IBAN, Company name and so on can only be changed if the user has a certain permission XY.
So far so good, on the client side I can check the permissions and disable those fields the user is not allowed to edit. But what would be the most elegant way to ensure on the server side that those fields have not been set without permission?
My problem is that I cannot track changes on the server side. Having #PreAuthorize on every setter is not an option too, because it would end in an authorization-massacre in each and every entity.
At the moment I am following a workaround: every field that is secured / depends on a given permission is passed as an argument to the entity-method and is excluded from the proxy. That way, values cannot be set using the proxy and I can check in my server code if the user has permissions. If not, nothing happens. If user has permissions, I set the values manually. But that produces a lot of boilerplate-code and ugly method signatures because the number of values passed to the method could get large.
I hope you understand my issue. I'm looking forward for your opinions and tips. Thank you in advance.
Well, you can receive many answers (different each other), and all of them could be right, so, at the end is your call. Wait for others answers. I am going to give you the approach that I followed (and it worked pretty well). :D.
Under my opinion, the server should do less as possible, so keep the logic for allowing modify each param on the server I think it is not a scalable solution (if your system has 1M users modifying everything at the same time, will your server work fluent?). I prefer let the client do the job (like Roomba :D).
For solving that problem, in our system we implemented an Access Control List solution. You can store in your db, on each user entity, a list with granted permissions. So, when that information arrives to the client (after user's log in, for example), you can get them, and show the fields that he/she is allow to modify.
Something like:
if (canModifyPersonalDetails(user.getAcls(), ...) ) {
//show labels ...
}
if (canModifyBankDetails(user.getAcls(), ...) ) {
//show labels
}
You can not avoid server call for log in, so it is not a big deal send the extra information (think about the ACLs could be simple list of integers 0 means personal details, 1 bank details....).
If you are dealing with very compromised information and you prefer do some stuff on the server, in that case probably I'd set up a security level, when you are persisting/updating your proxy, I'd do something like:
if (isAllowForPersonalDetails(user.getSecurityCode()) {
//update the modified personal details
}
if (isAllowForBankDetails(user.getSecurityCode()) {
//update the modified bank details
}
user.update();
I am a big fan of clear User GUI's, and a very big fan of let the server free as much as possible, so I prefer the first option. But if you have constraints for modifying user entity in db, or you prefer do not modify your views, or any constraint with security, maybe the second option is the best one for you.
Hope that helps!
I'm using devise/omniauth to do facebook authentication and works great. However, I would like to add a flow where an existing (non-facebook) user has ability to connect his account with facebook. This would require different facebook permissions. so i can't seem to find two things
how to use devise/omniauth to request facebook connect without logging out current user
request different extended permissions from user (different from those specified in the devise configuration file)
any ideas? thanks
Answer to 1 is pretty easy: just add a if path into the omniauth_callbacks_controller::process_callback method like this
# If a user is signed in then he is trying to link a new account
if user_signed_in?
if authentication.persisted? # This was a linking operation so send back the user to the account edit page
flash[:success] = I18n.t "controllers.omniauth_callbacks.process_callback.success.link_account",
:provider => registration_hash[:provider].capitalize,
:account => registration_hash[:email]
else
flash[:error] = I18n.t "controllers.omniauth_callbacks.process_callback.error.link_account",
:provider => registration_hash[:provider].capitalize,
:account => registration_hash[:email],
:errors =>authentication.errors
end
redirect_to edit_user_account_path(current_user)
This is what I do in my application and it works fine.
Regarding question 2 I do not know how to support 2 different facebook authentication configurations however I have hard time seeing how that is useful to users since they need a consistent experience across both path: "sign in using facebook" and "link your account to facebook".
(If you still want to pursue this path one idea I would explore is to create a new facebook application with its independent keys and configuration...)
Hope this help.
One simple way to implement multi-tier permissions is to use Facebook Javascript SDK(in addition to omniauth, if you want). You can simply specify different "scope" parameter, which specifies permissions required, at each call you want. What I'm doing is making omniauth provide a basic set of permissions, then, after the user has connected through omniauth(and thus stored their data in our DB), if further permissions are needed, we show them JS-based buttons which provide expanded sets of permissions. If you want to check what particular permissions a user has granted to you, you can simply use me/permissions API call.