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
Related
We have recently switched to Keycloak to handle the login to our website.
It's still possible to register and Keycloak has a user registration page, but I basically need to change the definition of 'registrating'.
By default it means "insert a new user in the DB with the info given by the user through the registration form". But that's not what we want, we already have all the users that CAN register in our DB, and registrating as a user pretty much means updating a record in our DB.
I have already made changes to the a few classes and redeployed them by packaging them and then adding the Jar to the \deployments directory. But I can't seem to find the classes that I have to change to get the registration page to behave the way I want.
How can I change the default behavior of the registration page? What classes do I have to change?
I've never do this, but i'd take a look to the user store SPI and authenticator SPI.
I suggest you in writing directly in the Keycloak discourse forum (https://keycloak.discourse.group/) . They will surely give you a hand.
PS: with SPI you'll add features to Keycloak, but in your case i think that you'll need also to change the GUI. See Keycloak Themes in the official doc.
I've been tasked to have my (Java-GWT) web app determine the environment it's in based on the hostname of the server the app is running in. This would be easy enough to do if this check existed in the code (via InetAddress.getLocalHost().getHostName() although not preferred I know), but the request is that I add this configuration to the web.xml via the method mentioned in the title.
I don't know much about defining security realms or jaas domains but what I need is simple. I simply need to read in the hostname of the server and if the string patter prod exists, set a flag or value that the app code can access and decide against. Hopefully this makes sense.
If this strategy seems like a flawed one altogether, I'm open to suggestions on the best way to have my app determine which environment it's running in.
If I understand well, you want you application to know what environment it is running on. This has nothing to do with security (or at least I don't see it)
I would set the environment descriptive name as a property external to the application, for example as a custom JNDI resource, system property o environment property. Preferable the first in order to let the application declare its dependency, via a <env-entry>
https://docs.oracle.com/cd/E19857-01/820-1639/6nda10e5g/index.html#bhanr
we have a complex infrastructure with WebSEAL, Websphere Portal and a couple of Wesphere AS' where we [obviously] want to set up SSO. we successfully configured TAI++ etc, but unfortunately default LTPA2 token name ("LtpaToken2") is not acceptable for compatibility reasons and we want to change it. Websphere AS 8.5, that we're using, has a special option in "General security -> Single Sign-on" to do so, but that doesn't work however; no matter what we enter, the token issued is still named "LtpaToken2" (well, yes we restarted the AS apparently ;P).
is it something known around websphere community? afaiu this can be customized by implementing a token factory and a token interceptor/validator (i.e. as is suggested here: Generate LTPAToken 2 in custom Web Application), but i'd expect the edit-box that supposedly does so to actually work.
BTW, i take it that renaming LTPA2 tokens is not at all possible in earlier Webspheres?
It is definitely possible since v8. I've tested it on 8.5.5.1 and works fine (I can set ltpa cookie to any name). Verify your settings accessing directly to WAS for example - in admin console, not via TAM. Your problem might be related to WebSEAL and Tai.
I don't quite understand what you mean that ltpatoken2 is not acceptable for compatibility reasons? It was always like that, so changing it will rather introduce incompatibilities, than keeping the default.
I'm working on implementing a role-based authorization service under WS Liberty.
There are two main goals:
if the user without the correct user group tries to open a restricted url, show an error page
the user should see a menu, listing all pages available for him
My question is: are there best practices to implement this behaviour? Should I create the first part in server.xml AND the second part in the appropriate view?
(this way the "logic" will be stored in two different parts of the code, and for example if I have to add a new URL, I have to insert it into two different places)
So is there a way to store this role-URL mapping in one place?
Thanks,
krisy
In you application you can protect links checking roles (pseudo code, some frameworks have already custom tags for it):
if(request.isUserInRole("roleX")) {
// render menu item for roleX
}
By default, if user is already logged in and tries to access page that is restricted for him, he will receive 403 Not authorized, you can provide error page for that code via web.xml configuration.
In the server.xml via Application binding element you provide only mapping from your application roles to groups defined in the registry. Depending on the registry type you will be able to add/remove users to the given group granting or rejecting them right for example via server.xml or LDAP management tool in case of LDAP registry.
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