It seems that when login with remember me feature, the user attributes (comming from AttributeRepository) are not refreshed.
The use case :
A user logs on monday. Its attributes are retrieved.
On tuesday, its attributes change (roles for examples).
On Wednesday, when it returns to the sit and authenticate via Rememberme, its old attributes values are returned by CAS server.
If the user logs out and then logs in, its attributes are normally refreshed.
How to refresh the user attributes when login via remember me ?
I'm using CAS server 3.5.2.
Currently, those attributes are not refreshed. The attributes are retrieved at TGT generation time and serialized to the database (they are stored with the principal which is attached to the ticket). The CAS4-api branch solved that issue by always delegating to the underlying attribute repository which could decide to cache the attributes for a period of time. There is some work being done to transfer some of the API-branch code into the trunk, but not all of it is. If you want to see this in there, you should open a JIRA issue with this bug. I can provide details in the ticket on why this is happening and ways it can be fixed.
Related
I have successfully installed liferay 7 and configured CAS 3.6 for SSO. Everything is working fine. I was able to create users, assign roles, create pages etc etc.
After few days, I was trying to create a new user via admin, I got warning "User 30810 is not allowed to access URL https://mysite:8443/group/control_panel/manage and portlet com_liferay_users_admin_web_portlet_UsersAdminPortlet". I could not able to create user. and from then that user does not have any permission that I use to do earlier.
I googled a lot on this, got few suggestions like
1) Adding below in portal-ext.properties:
redirect.url.security.mode=domain
redirect.url.domains.allowed=*.mysite.com
session.timeout.warning=0
session.timeout.auto.extend=true
2) Some links:
https://web.liferay.com/community/forums/-/message_boards/message/92226678
3) Somewhere it is mentioned that this it is bug with liferay started from liferay 7 GA4
4) If you read the link, it is mentioned that it related to Guest user and session expiration that starts causing this issue etc.
Had any one gone through this issue? Is there any solution or workaround for this?
I could not able to update this question with all the option I tried or solutions that is mentioned on google or liferay's official jira sites however I will keep updating this question with proper references.
Meanwhile
Do provide your suggestions/solutions.
"this starts happening when some session automatically logs out"
This phrase tells me several things, like the possibility of an user logging out even though you set "session.timeout.auto.extend".
Two basic scenarios where this can happen is:
When you close your tabs, after the assigned timeout, the user will be logged out. And when you got back, especially after a browser crash or using the back button, your browser used old data.
When you have the auto session extension working with a big timeout, leading to the possibility that the session timeout configured in Liferay being bigger than the one configured on the server.
On the last case, one might be interested on completed the config you exposed with short timeouts.
session.timeout.warning=0
session.timeout.auto.extend=true
session.timeout=5
session.timeout.redirect.on.expire=true
I know it is an old thread but it may help someone...
The "extend session" functionality is not working correctly and the final user session is expired, so when they try to log in, they have the wrong CSRF token from the previous session:
You have to double-check that the session.timeout Liferay portal.properties has the same value as the session timeout configured in your application server.
You have also check that the session.timeout.auto.extend.offset is greater than 60 seconds to avoid having problems with the chrome javascript intensive throttling
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
My title is probably vague so please check my situation below.
I have a web application to manage a list of employees. The application is set up in a hub-spoke pattern where clicking an employee from the employee list redirects to a new window showing the chosen employee's personal details for possible updates.
The application uses HTTPS. The employee list and details are retrieved via GET while the details are updated via POST. The application uses HTTPS and all users (there are only a few of us) have the authority to retrieve and update employee details.
My question is, will it still be required or suggested to check the employee ID (the primary key) during update/post operations? A sophisticated user can theoretically change the employee ID before the POST and update another employee's details even without pulling out the 2nd employee's record. Still, even if that user somehow fools the interface, any of his "hacks" would simply be acceptable since the user can retrieve and update any employee anyway.
So in my case, would you still consider it necessary to enforce a mechanism so that only the currently shown record is updateable? If yes, what are the accepted practices for implementing this? Thanks
Many web based systems are designed to be stateless. The main reason is to allow multiple sessions/windows.
You could potentially store the currently edited employee ID in a session variable and only allow changes to that employee ID, however, what if the user has two browser windows open in the same session? Now, you have to keep the currently edited employee ID for each window. Well, you don't have this information, so you have to store the employee ID in the form itself, and this is all editable by the client.
So, instead, simply enforce the rules on the server, and if they have permission to edit that employee, let them.
Ensure that your system is using HTTPS to prevent man in the middle attacks, escaping all output to prevent cross site scripting (XSS), and requiring POST for all updates as well as using sessions and form tokens to prevent cross site request forgery (CSRF). Once you've done that, any employee ID manipulation will likely be self-inflicted, and your job isn't to protect the user from themselves.
What you usualy do is - click on a row, get the employee ID and send it to the server, retrieve information by ID and publish it to the user. Usualy you keep the ID as some jind of hidden value, so when you update, you update this ID. And, usualy, you don't allow ID changes. IMO no need of checking ID, but if you think some one can jump over, just check if the ID of the page is the same you have in the hidden value.
I'm writing a GWT application where users login and interact with their profile. I understand that each form entry needs to be validated on the server, however, I am unsure about potential security issues once the user has logged in.
Let me explain. My application (the relevant parts) works as follows:
1 - user enters email/pass
2 - this info is sent back to the server, a DB is queried, passwords are checked (which are salted and hashed)
3. if the passwords match the profile associated w/ the email, this is considered success
Now I am unsure whether or not it is safe to pass the profile ID back to the client, which would then be used to query the DB for information relevant to the user to be displayed on the profile page.
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
-Nick
What you are dealing with here is a session management issue. Ideally, you want a way to keep track of logged in users (using random values as the session key), know how long they have been idle, be able to extend sessions as the user is using the site, and expire sessions.
Simply passing the profile ID to the client, and relying on it to send it back for each request is not sufficient - you are correct with your concern.
You want to keep a list of sessions with expiration times in a database. Every time an action is executed that needs user permissions (which should be pretty much everything), check to see if the session is still valid, if it is, extend it by however long you want. If it is expired, kill the session completely and log the user out.
You can store your session keys in a cookie (you have to trust the client at some point), but make sure they are non-deterministic and have a very large keyspace so it cannot be brute forced to get a valid session.
Since you're logging a user in, you must be using a backend that supports sessions (PHP, .Net, JAVA, etc), as Stefan H. said. That means that you shouldn't keep any ids on your client side, since a simple id substitution might grant me full access to another user's account (depending on what functionality you expose on your client, of course).
Any server request to get sensitive info (or for any admin actions) for the logged in user should look something like getMyCreditCard(), setMyCreditCard(), etc (note that no unique ids are passed in).
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
Stefan H is correct that you can solve this via session management if your session keys are unguessable and unfixable.
Another way to solve it is to use crypto-primitives to prevent tampering with the ID.
For example, you can store a private key on your server and use it to sign the profile ID. On subsequent requests, your server can trust the profile ID if it passes the signature check.
Rule 1 - Avoid cooking up your own security solution and use existing tested approaches.
Rule 2 - If your server side is java then you should be thinking along the lines of jsessionid. Spring Security will give you a good starting point to manage session ids with additional security features. There will be similar existing frameworks across php too (i did not see server side language tags in the question).
Rule 3 - With GWT you come across javascript based security issues with Google Team documents and suggests XSRF and XSS security prevention steps. Reference - https://developers.google.com/web-toolkit/articles/security_for_gwt_applications
I'm using my own User class as and entity provider for security system in symfony 2.0.
I noticed that on each reload of the page symfony is fetching user from db:
SELECT t0.id AS id1, t0.username AS username2, t0.salt AS salt3,
t0.password AS password4, t0.email AS email5, t0.is_active AS
is_active6, t0.credentials AS credentials7 FROM w9_users t0 WHERE
t0.id = ? Parameters: ['23'] Time: 4.43 ms
Is there any easy way to disable this behaviour? Maybe serialize user data in session variables or cache them some way?
You can change this behavior in the refreshUser method of your UserProvider.
You should be careful when doing this with doctrine: There is an issue at FosUserBundle github, explaining the pitfalls:
Storing it in the session would lead to several issues, which is why it is not done by default:
if an admin change the permissions of a user, the changes will have an effect only the next time you retrieve the user from the database. So caching the user must be done carefully to avoid security issues
if you simply reuse the user which was serialized in the session, it will not be managed by Doctrine anymore. This means that as soon as you want to modify the user or to use the user in a relation, you will have to merge it back into the UnitOfWork (which will return a different object than the one used by the firewall). Merging will trigger a DB query too. And requiring such logic will break some of the built-in controller which are expecting to be able to use the user object for updates.