I have an application using Acegi (earlier version of Spring Security) and LDAP for logins. Now, a specific scenario requires me to discover user's LDAP groups at arbitrary time (not at login time).
Is it possible to use already set up Acegi to handle this situation?
I'm thinking of using the configured LdapAuthProvider (or LdapAuthPopulator or whatever's appropriate) to get all the groups associated with a given username. Is this possible?
If yes, please, please, give some hints how it should be done...
You should use DefaultLdapAuthoritiesPopulator.getGroupMembershipRoles(String userDn, String username).
Related
See Edit-1 below for sum-up question
I am using Spring Security libraries (v3.0.5) to handle authentication for a web application (deployed in JBoss AS7). The account management is handled by an IdM on top of OpenLDAP.
When a new account is created, by default it is created with the "nsaccountlock" operational attribute set to "true". We can confirm that the account is "Disabled" by logging into the IdM web portal and listing the users - new users are listed as Disabled.
The problem is that our web application seems to ignore that nsaccountlock attribute completely when it searches for a user entry. The springframework logs report "Enabled: true" for all accounts that attempt to authenticate, whether they have the nsaccountlock=true or false.
I have searched through as much of the springframework source code as I can find, and I can not find anything that is actually setting the "enabled" state to false (see org.springframework.security.ldap.userdetails.LdapUserDetailsImpl and any subclass). I would have expected it to happen in org.springframework.security.ldap.userdetails.LdapUserDetailsMapper.mapUserFromContext() but it definitely does not set the Enabled flag anywhere.
The LDAP lookup and entry retrieval is configured in several .xml files (which I am unfortunately unable to post here at the moment) that define the use of classes such as org.springframework.security.ldap.authentication.LdapAuthenticationProvider, org.springframework.security.ldap.search.FilterBasedLdapUserSearch, etc.
Should I be using a different type of org.springframework.security.core.userdetails.UserDetails implementation to capture the disabled state from LDAP? Am I missing some obvious configuration element that would indicate how Spring can determine the disabled state of the LDAP entry?
Note: I can configure the LDAP search to fetch the "nsaccountlock" as an attribute in the UserDetails response, and the attribute is logged correctly
(whether the value is true or false) but it still does not affect the "enabled" boolean value. It just acts as another bit of metadata (like phone, address, email, etc).
Edit-1
I may have been asking the wrong question up front. Ultimately, I would like to know this:
What would lead LdapUserDetailsImpl.isEnabled() to return false? i.e., What do we need to do in order to make sure Spring Security recognizes disabled accounts?
I'm hoping this a matter of configuration. I imagine it has something to do with the AuthenticationManager (we use org.jasig.cas.authentication.AuthenticatoinManagerImpl)
Thanks for the help, and I apologize for the messy question.
As far as I know OpenLDAP and the LDAP protocol, nsaccountlock is not an attribute which is used by OpenLDAP to keep track of locked account, it is an attribute which was used in Sun Directory Server (Sun LDAP Directory).
But from the point of view of OpenLDAP it is the same as any other informative attribute.
If you want to manage a password policy you have to implement the overlay ppolicy which is described here
I'm creating a simple web app that has a user login. I'm trying to use Spring Security to manage authorization and I want to know if it is possible to use SS without setting up roles. There is no admin or special permissions, a user is either logged in or they aren't.
All tutorials I found make you setup a roles table and userroles join table in your database and the same entities in your files. This seems like overkill for what I want. Is it possible to just use SS to check a username and password and log the user in if they match what is in the database without doing all the role stuff?
You can use isAuthenticated(). See more in Spring documentation: http://docs.spring.io/spring-security/site/docs/3.0.x/reference/el-access.html
I do not think you have to setup roles in spring security.
And in my opinion, the role is for different page access, like you have admin and normal user, and you want to let the different roles go to different pages.
You can use authorities="ROLE_USER" everywhere, if you just have a small application.
Hope this can help you.
I am using Tomcat 7.0, Spring 4.0.2, Web Module 3.0 in eclipse for my web application. There is one requirement in my application that one user must not allow to login from two different clients. Along with this I need to consider this.
The solution I can think :
--> Declaring one static Set at app level.
--> Check before every check whether username contains in that Set or not, if contains then I will not allow to login.
--> Add username in Set after every login in Set.
--> Remove username after every logout from Set.
But I cannot think all scenarios when this solution will fail. I think when user will close browser directly, this will not work. Please help to find out all scenarios and also proper solution which will handle all scenarios. Thanks in advance.
Spring Security supports this out of the box. Can you migrate your authentication process to use Spring Security?
See section 2.3.3 Concurrent Session Management below:
http://docs.spring.io/spring-security/site/docs/3.0.x/reference/springsecurity-single.html
In my web application, there are times when an authenticated admin might want to impersonate another valid user of a system without having to know that user's password.
How can I use Spring Security to give admin users the ability to impersonate normal (non-admin) users of the system?
The Spring Security documentation is silent on this and I can't find anything anywhere. Surely someone must have solved this.
Thanks!
It's in the Spring Security 3 and Spring Security 4 docs aptly named, "Run-As Authentication Replacement."
The AbstractSecurityInterceptor is able to temporarily replace the Authentication object in the SecurityContext and SecurityContextHolder during the secure object callback phase.
I believe the recommended way to do this in Spring Security is with the Domain Access Control lists, see GrantedAuthoritySid #
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/domain-acls.html
However, impersonating another user is more than just having a "delegate identity", you should also consider the implications on logging:
Do you want your logging to appear as Original User or Impersonated User (or both?)
Do you want the "impersonation" to show only what the impersonated user sees, or the superset of permissions of the Original User and Impersonated User?
Yet another possibility is to create a "log in as" feature, which essentially changes the principal identity of the current session - or starts a new session with the impersonated identity.
In all of the above, you may inadvertantly open up a security issue - so I think this is why impersonate-style features are not that common place. Rather, designs trend towards Role Based Access Control (RBAC) or Attribute Based Access Control (ABAC). Using RBAC / ABAC, you could create a delegate style feature where you create delegate attributes/roles - and in the special cases where you need to show the source/target of the delegation (e.g. for audit logs), you handle those as corner cases.
If you want an admin user to be able to impersonate another user (eg for QA/Testing purposes), have a look at the SwitchUserFilter
A decent example of the XML config you need is provided here
In a banking or similar application there are usually several roles defined and associated privileges required (for example a normal user could only do transactions but not post it while a supervisor can verify and post them, sort of maker/checker). We also need to add new roles and privileges in the system (not sure about the latter).
How do you achieve this Role Based access in a Spring/Hibernate application? Especially in terms of scaling up to add new roles/privileges. Can Acegi (I never used it) help? Any other idea would be appreciated that can help me achieve the above.
Thanks,
As duffymo mentioned, Acegi has been renamed to "Spring Security" and it's what I would recommend if you're already working with Spring.
There's more documentation online for Acegi than Spring Security, so if in doubt you can find useful information in the Acegi docs/tutorials as well as the more recent Spring stuff.
If you can design your user table to fit with Spring Security's concept (user name, password, roles, each with certain specified types and names) then you can use Spring Security's DAO classes right out of the box; if not, you build a tiny adapter class to hook up Spring Security to your database for the user query.
You can specify required roles per servlet/URL or even at the method level. It took me a day or two to wrap my head around the concepts involved, but after that configuring it was reasonably easy, and I was happy that they've already solved most of the kinds of problems that arise in connection with Web security.
Yes, Spring Security (formerly known as ACEGI) can do it.