I'm using symfony 1.4 and the sfGuardDoctrinePlugin, I've got it installed and setup fine but I have the following problem:
If I login as an admin and update the permissions for a user, that user must logout then login again before having the newly added credential/permission.
Is there a way around this?
I'm not sure how easy this would be to fix. When a user logs in I think their credentials are added to their session attributes there and then. So when the admin updates their credentials their session still holds the old credentials. This means any call to hasCredential isn't "live".
Thanks
This would add extra queries to each and every request to your application. You could force update of the credentials by $user->getSfGuardUser()->refresh(true), which would reload the entity and all its relations (and thus its permissions).
Thanks for your answer, I've modified the processForm function of the sfGuardUser module's actions class.
If I login and change my own permissions, the session is updated there and then.
My problem is that if I edit the user permissions of another user, I would need to edit their session data. To solve this I enabled database sessions, so I now have sessions saving there instead of to file. So my next problem is how to isolate the session for the other user.
The sessions database has the following columns: sess_id, sess_data, sess_time.
sess_data is serialized and that is what I would need to update.
But I think symfony updates the session ids quite often and it would be hard to always isolate the correct session for the other user.
I think that it would also be slow to try and unserialize, check user_id then reserialize the data. I would need a user_id column I think.
I know this is an old question, but I recently had this same problem and it took me way longer than it should have to find the answer (which was posted in Symfony's code snippet section). Paste this function in your myUser class and all problems go away:
/**
* Overridden method that actually reads the permission from DB
* instead of relying on data present when the user logs in.
*
* #param string permission name
*
* #return boolean true if the user has credential
*/
public function hasCredential($permission_name)
{
if (!$this->isAuthenticated()) {
return false;
}
$gu = $this->getGuardUser();
$groups = $gu->getGroups();
$permissions = $gu->getPermissions();
$permission_names = array();
foreach($permissions as $permission) {
$permission_names[] = $permission->getName();
}
foreach($groups as $group) {
$group_permissions = $group->getPermissions();
foreach($group_permissions as $group_permission) {
$permission_names = array_merge($permission_names, array($group_permission->getName()));
}
}
$permission_names = array_unique($permission_names);
return (in_array($permission_name, $permission_names)) ? true : false;
}
Related
I've been reading a lot about session fixation attacks and the most popular solutions I've come across are changing the SessionID when user logs in and creating an additional cookie using a GUID to verify the user "belongs" to the SessionID.
My question is this: Isn't it enough to just delete the SessionID cookie (ASP.NET_SessionID) to ensure a new SessionID is generated?
In MVC 5, when the user logs in an additional encrypted user claims cookies is created (AspNet.ApplicationCookie) which Identity uses to authenticate the user upon each request. The additional "GUID cookie" seems unnecessary.
I’m originally a .NET desktop application developer writing my first MVC app and the learning curve has been a bit steep… although refreshingly enjoyable.
Thanks for any help.
Let me try to explain the issue and the solution by using comparisons between desktop and web apps (both in .Net)
When you start your desktop app, the first thing the app shows is a login screen, after which your access to the UI is granted. Now, each time the app's exe is started, it writes the "RunID" to a text file and shows the login screen. The RunID is how the rest of your usage of the app is going to be tracked/correlated.
Assume for a second that the file was on C:\RunID.txt.
An attacker (hacker) can start the exe (without logging in) on Machine1 and copy the contents of C:\RunID.txt to Machine2. Now as soon as you log in on Machine1, the RunID token from Machine1 will also work on Machine2, this is called session fixation.
The ideal way to fix it is to ABANDON the pre-authentication token, and issue a NEW Post-Authentication token. So, you would get a new Token after authentication (or in your case, an additional GUID) which will NOT EXIST on Machine2 and hence provide a level of security in addition to the RunID random token (Session ID)
Let me know if you'd like further explaination, but that is why even in MVC, you should abandon the previous session and create a new session post-auth to avoid session fixation, as a compensating control, you can add a GUID cookie too correspond with the Session ID cookie.
You can do this to avoid that situation:
SessionIDManager Manager = new SessionIDManager();
string NewID = Manager.CreateSessionID(Context);
string OldID = Context.Session.SessionID;
bool redirected = false;
bool IsAdded = false;
Manager.SaveSessionID(Context, NewID, out redirected, out IsAdded);
Response.Write("Old SessionId Is : " + OldID);
if (IsAdded)
{
Response.Write("<br/> New Session ID Is : " + NewID);
}
else
{
Response.Write("<br/> Session Id did not saved : ");
}
Support link:
Link
I have a Grails application that is successfully using the latest spring-security-core:2.0-RC4 and spring-security-ldap:2.0-RC2. Users can login perfectly using
grails.plugin.springsecurity.ldap.search.base setting for LDAP login authentication.
There is a different setting for the rememberMe userDnBase (mapper) and that setting is:
grails.plugin.springsecurity.ldap.rememberMe.usernameMapper.userDnBase
The LDAP authentication grails.plugin.springsecurity.ldap.search.base is set to ou=people,dc=sitcudy,dc=edu. As mentioned above - the logins work fine because there is a property called searchSubtree that I have set to true. Unfortunately, the searchSubtree setting does not hold true and carry through consistently within the 'remember-me' portion of the code (.ldap.rememberMe)*. The remember-me portion of the code uses a map for the base DN, grails.plugin.springsecurity.ldap.rememberMe.usernameMapper.userDnBase
so I put in a string in the config.groovy file (the same as for the authentication piece) to map to the base DN of ou=people,dc=sitcudy,dc=edu.... which gets mapped to the DN for the LDAP user look up upon returning to the application for persistence cookie login.
Here's where my problem comes in, most users are segregated into different DIT's in our LDAP system. For example, some uses are in ou=staff,ou=people,dc=sitcudy,dc=edu while other users are in ou=students,ou=people,dc=sitcudy,dc=edu therefore, because of the remember me mapping, upon returning to the application, once verifying the cookie, the code tries to bind users in this format, uid=reuben_marcus,ou=people,dc=sitcudy,dc=edu which doesn't exist. What does exist is uid=reuben_marcus,ou=staff,ou=people,dc=sitcudy,dc=edu therefore the cookie is destroyed and the login (IS_AUTHENTICATED_REMEMBERED) never occurs.
If I change grails.plugin.springsecurity.ldap.rememberMe.usernameMapper.userDnBase
to ou=staff,ou=people,dc=sitcudy,dc=edu the remember me functionality works perfect for all staff members, but it doesn't work for all other people - students, faculty etc.
The main setting in question below for me in this issue is:
grails.plugin.springsecurity.ldap.rememberMe.usernameMapper.userDnBase
Since this is just a mapping and there isn't allowance for multiple userDNBases or searchSubtree search.. How is the ‘remember-me’ code supposed to find users that do not fall into this base DN setting...??
I wonder if I'm doing something wrong or if this is a feature request to have the ‘remember me’ code have options for multiple mapping userDNBases or allow it to have a searchSubtree search capability.
Relevant settings from my config.groovy:
grails.plugin.springsecurity.ldap.mapper.roleAttributes = 'sitPriRole,uid'
grails.plugin.springsecurity.ldap.context.managerDn = 'uid=SPS_bind,ou=People,dc=sitcudy,dc=edu'
grails.plugin.springsecurity.ldap.context.managerPassword = 'xxx'
grails.plugin.springsecurity.ldap.context.server = 'ldap://ds01.sitcudy.edu:389'
grails.plugin.springsecurity.ldap.authorities.groupSearchBase ='ou=Groups,dc=sitcudy,dc=edu'
grails.plugin.springsecurity.ldap.search.base = 'ou=People,dc=sitcudy,dc=edu'
grails.plugin.springsecurity.ldap.search.searchSubtree = true
grails.plugin.springsecurity.ldap.auth.hideUserNotFoundExceptions = false
grails.plugin.springsecurity.ldap.search.attributesToReturn = ['uid', 'sitPriRole', 'mail', 'displayName']
grails.plugin.springsecurity.providerNames = ['ldapAuthProvider', 'anonymousAuthenticationProvider', 'rememberMeAuthenticationProvider']
grails.plugin.springsecurity.ldap.authorities.retrieveGroupRoles = false
grails.plugin.springsecurity.ldap.authorities.retrieveDatabaseRoles = false
grails.plugin.springsecurity.password.algorithm = 'SHA-256'
grails.plugin.springsecurity.rememberMe.persistent = true
grails.plugin.springsecurity.rememberMe.persistentToken.domainClassName = 'od.PersistentLogin'
// role-specific LDAP config
// grails.plugin.springsecurity.ldap.useRememberMe = true
grails.plugin.springsecurity.ldap.rememberMe.detailsManager.attributesToRetrieve = null
grails.plugin.springsecurity.ldap.rememberMe.detailsManager.groupMemberAttributeName = 'uniquemember'
grails.plugin.springsecurity.ldap.rememberMe.detailsManager.groupRoleAttributeName = 'cn'
grails.plugin.springsecurity.ldap.rememberMe.detailsManager.groupSearchBase = 'ou=Groups,dc=sitcudy,dc=edu'
grails.plugin.springsecurity.ldap.rememberMe.detailsManager.passwordAttributeName = 'userPassword'
grails.plugin.springsecurity.ldap.rememberMe.usernameMapper.userDnBase = 'ou=People,dc=sitcudy,dc=edu'
grails.plugin.springsecurity.ldap.rememberMe.usernameMapper.usernameAttribute = 'uid'
This problem was mentioned here: Grails - Spring security plugin ldap: remember me not working
I found a workaround for this by registering custom TokenBasedRememberMeServices bean in resources.groovy.
I didn't use persistent logins functionality available in grails-spring-security-ldap plugin, because I found it incompatible with my Active Directory tree layout. Most probably, this could be customized by extending LdapUserDetailsManager but in my situation I found it unnecessary to store token in database.
I used regular spring security remember me cookie option but without storing user password in the cookie. I extended the following methods from TokenBasedRememberMeServices
makeTokenSignature - make token signature without password field
processAutoLoginCookie- if cookie exists, then retrieve username from cookie token and fetch ldap user details (I had to write my own method retrieveUserFromLdap() explained later)
onLoginSuccess - this gets triggered when user logs in with remember-me option checked. Here, I'm removing password and saving token signature to cookie.
To fetch user details and roles from LDAP it might depend on specific implementation but my method looks like this:
static protected UserDetails retrieveUserFromLdap(String username) {
def ldapUserSearch = Holders.applicationContext.getBean('ldapUserSearch')
def userContextMapper = Holders.applicationContext.getBean('ldapUserDetailsMapper')
def authoritiesPopulator = Holders.applicationContext.getBean('ldapAuthoritiesPopulator')
def userContext = ldapUserSearch.searchForUser(username)
def userAuthorities = authoritiesPopulator.getGrantedAuthorities(userContext,username)
userContextMapper.mapUserFromContext(userContext,username,userAuthorities)
}
I had a Posting on a blog about Sessions AND Cookies. Here are details
Sessions
Sessions are More Secure
Sessions are on the server
Cookies
Cookies are On client side
Less Secure
Once it is disable on browser the difficult to use.
On the basis of above argument i used sessions in Login system to keep UserId,UserName & roleName
Now on the the basis of roleName i will decide either this is Admin to enter to administrator section or not.
I have used this Code in Model in MVC
public bool LoginMe()
{
Int64 Error;
//create db
Database db = DatabaseFactory.CreateDatabase("DBContext");
DbCommand dbCommand = db.GetStoredProcCommand("ValidateUser");
db.AddInParameter(dbCommand, "#Username", DbType.String, this.UserName);
db.AddInParameter(dbCommand, "#Password", DbType.String, EncryptPassword(this.Password));
db.AddOutParameter(dbCommand, "#Error", DbType.Int64, 10);
DataSet dsResult = db.ExecuteDataSet(dbCommand);
Error = Convert.ToInt64(db.GetParameterValue(dbCommand, "#Error"));
if (Error == 1100)
{
try
{
var query = (from o in dsResult.Tables[0].AsEnumerable()
select new AllUser
{
UserId = o.Field<int>("UserId"),
UserName = o.Field<string>("UserName"),
roleName = o.Field<string>("roleName"),
}).Single(); // this will raise an exception if there isn't just one record returned
Session["UserId"] = query.UserId;
Session["UserName"] = query.UserName;
Session["roleName"] = query.roleName;
return true;
}
catch {
// do nothing and let method return false as something has gone wrong.
// add logging here if you are using it to show there has been a problem
}
}
return false;
}
I used it in View like #Session["UserId"]
Now an expert comment on this like
If you aren't using https and securing the session cookie then this might make it easy to hack your site, although that's the same for any session based site (nearly all of them)
It might be nice to add some check so that if you remove a user's rights, the session variables are deleted the next time that user requests something from the server,
otherwise they could carry on using the site even though their account it banned.You'd have to decide if this is likely and then how you want to do this (using an authorization filter maybe.)
Above comments confused me.Can any body make it clear?What is the best way to keep these information?
Session state uses client tickets to identify the server-side session, it may be susceptible to session ID spoofing and injection attacks.
So, to hack session values one would require hacking the remote-server.
And yes, for highly secure application(such as online banking) use https.
http://msdn.microsoft.com/en-us/magazine/cc163730.aspx#S9
Secure sockets layer (SSL) should be used to prevent network-level sniffing of session IDs, authentication tickets, application cookies, and other request/response information.
Can session value be hacked?
Use HTTPS if you application handles sensitive information(credit-card number,account num,passwords).
Store the User object (model with userId,username,role) in the session than separate attributes
Set setHttpOnly attribute for SESSION_ID.
It might be costly to refresh the User object stored in session before invoking every operation to reflect the current rights stored in database.
As a application administrator I would like to be able to log off any user, for example, after setting the flag "enabled = false" to the selected user. Is it possible in spring-security?
I should add that my application allows the use of "remember Me" for users.
I'm using:
grails 2.2.1
plugin spring-security-core 1.2.7.3
Settings spring-security-core (config.groovy):
grails.plugins.springsecurity.useHttpSessionEventP ublisher = true
grails.plugins.springsecurity.useSessionFixationPr evention = true
grails.plugins.springsecurity.userLookup.userDomai nClassName = 'com.app.User'
grails.plugins.springsecurity.userLookup.authority JoinClassName = 'com.app.UserRole'
grails.plugins.springsecurity.authority.className = 'com.app.Role'
grails.plugins.springsecurity.userLookup.usernameP ropertyName = 'email'
grails.plugins.springsecurity.securityConfigType = "Requestmap"
grails.plugins.springsecurity.rejectIfNoRule = true
grails.plugins.springsecurity.requestMap.className ='com.app.Requestmap'
grails.plugins.springsecurity.requestMap.urlField= 'url'
grails.plugins.springsecurity.requestMap.configAtt ributeField='configAttribute'
grails.plugins.springsecurity.rememberMe.cookieNam e = 'remember_me'
grails.plugins.springsecurity.cacheUsers = false
grails.plugins.springsecurity.rememberMe.tokenVali ditySeconds=604800
Has anyone had a similar problem may be?
thank you in advance :)
Setting the UserDetails.enabled flag to false should cause a DisabledException to be thrown on the user's next secure request. This can either send the user to the default authfail handler, or you can configure an exception handler in your UrlMappings to send the user to a custom controller or action.
If you're not using the enabled flag anywhere else in your application, you can direct the DisabledException to an action which clears the authentication session (and rememberMe), then resets the enabled flag.
Another possible way would be to create a custom filter and inject it into the spring security filter chain in your Bootstrap.
Both the url exception mapping and the filter configuration are described in the Spring Security Plugin Documentation
Thanks Codelark, I'm reading about filters and try to use them :)
Unfortunately, when I set enabled = false for the selected user application does not redirect it to "/login /authfail".
Best of all, the changes (enabled = false) are visible to the user profile but the lack of the desired effect.
I would add, I tried to set "expireNow" a user session:
def expireSession(User user) {
def orginalUser = springSecurityService?.principal.username
springSecurityService?.reauthenticate(user?.email) //modified user np: test#app.com
springSecurityService?.reauthenticate(orginalUser) //admin np: admin#app.com
sessionRegistry.getAllPrincipals()?.each { princ ->
sessionRegistry.getAllSessions(princ, false);
if(princ?.username?.equals(user?.email)) { //killing sessions only for user (test#app.com)
sessionRegistry.getAllSessions(princ, false)?.each { sess ->
sess.expireNow()
}
}//if
}//each
}//expireSession
Namely sessionRegistry really gets active sessions for each user, but by calling:
sess.expireNow()
The result is that calling expireSession (user) for the same user again, the session is no longer visible. Which is understandable because it has expired.
But in spite of expired user session. He may continue to work in the application. The application does not log you off
I have s symfony 1.4 with Doctrine and sfDoctrineGuardPlugin.
I am experiencing a problem with loading fixtures for sfGuardUser which are made from symfony doctrine:data-dump
The core of the problem is that the passwords in the fixture file are not encrypted and they will be encrypted in the process of fixture loading.
In the other hand - when we dump data from the data base, the passwords are already encrypted and if we try to load them again, the value of the password will be rehashed for the second time.
Does anybody know how to avoid this situation?
I am using this process to prevent data loss when the model needs to be changed. If anybody knows other solution for this particular problem, I will appreciate!
There's a solution to this in the old symfony forum.
In short: create a setEncryptedPassword function in your user model like this:
public function setEncryptedPassword($v)
{
if ($v !== null) {
$v = (string) $v;
}
if ($this->password !== $v) {
parent::_set('password', $v);
}
return $this;
}
And in your dump change all password occurences to encrypted_password.