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.
Related
I have an application with Vaadin 8 and Spring Boot. Currently, I'm in progress of adding authentication to this app. So, I enabled Spring Security and started tinkering with it. Basically, I followed this tutorial: https://vaadin.com/tutorials/securing-your-app-with-spring-security/setting-up-spring-security
The approach, described there, works fine, however, I'm slightly disturbed by the fact that /VAADIN/** path needs to be publicly available (otherwise, Vaadin doesn't work). I mean, of course, I have protected particular pages by their paths (e.g. /admin) and unauthenticated users won't be able to open them, but isn't exposure of /VAADIN/** path dangerous? What if some hijacker tries to send some request to the Vaadin servlet outside of the UI (by simply curling it) with some specific headers/parameters? Is it possible that by formatting such request in some malicious way, the data will be actually returned to this hacker, bypassing Spring Security?
but isn't exposure of /VAADIN/** path dangerous
It is not dangerous per ce. The framework itself has just some generic parts there, like static resources for the client, like the widgetset and theme. Having said that, it is of course to be noted it application design. For example you should not put something that includes confidential info in your app as ThemeResource, but use ClassResource instead and things like that.
I have my application on production on some domain name ABC.com. In my code i am redirecting user to other page based upon on some action
response.sendRedirect(request.getServletContext().getContextPath() + "/time");
But by the above it get redirected to localhost:8080//time
but instead of this i want it to get redirected to ABC.com/time
How can i do this? A simple solution coming to my mind is that i should set some environment variable for production and instead of using
request.getServletContext().getContextPath()
, i will use environment variable value i.e. ABC.com
If you really need the domain under which your server can been reached, then the environment variable way is the only way that works all times (for example even if there is a proxy in front of your server...)
It seems to me that this should work with the domain that you want, provided that the application is operating from said domain. Right now you are probably using a development environment on your localhost, which means the servlet is operating on localhost:8080 and will also pass that back as it's path. When you deploy your application it should work.
If you need to redirect to the production version even though you are running in a development environment, you should hardcore the URL in a configuration variable of sorts. I prefer using .conf files and reading those at runtime since it allows you to alter their contents on the fly easily.
One minor thing that might cause issues is the double slashes. A path or URL will end in a slash so you don't have to append the second one. Simply doing + "time" should be enough.
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'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
I need to prevent Session Fixation, a particular type of session hijacking, in a Java web application running in JBoss. However, it appears that the standard idiom doesn't work in JBoss. Can this be worked around?
This defect (found here) points the way to the solution. The Tomcat instance that runs in JBoss is configured with emptySessionPath="true", rather than "false", which is the default. This can be modified in .../deploy/jboss-web.deployer/server.xml; both the HTTP and AJP connectors have this option.
The feature itself is used to eliminate the context path (eg. "foo" in http://example.com/foo) from being included in the JSESSIONID cookie. Setting it to false will break applications that rely on cross-application authentication, which includes stuff built using some portal frameworks. It didn't negatively affect the application in question, however.
This problem and the specific case in which it occurs is a problem in Tomcat as well as JBoss. Tomcat shares the emptySessionPath="true" effect (and actually JBoss inherits it from Tomcat).
This really seems like a bug in Tomcat and JBoss when you are trying to prevent session fixation attacks but the servlet spec (at least version 2.3) does not actually require the JSESSIONID to be defined or redefined according to any specific logic. Perhaps this has been cleaned up in later versions.
One workaround is to store the client address in the session. A response wrapper should validate the client address set in the session is same as the one accessing the session.
I came to know below code setting snippet from one of the forum. And I added below lines. But when I print the session ID after and before log in into the application it is same. How would I test session Fixation.
D:\jboss-5.1.0.GA\bin\run.cof file and add the below line.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false"
in each context.xml of the jboss applications.
D:\jboss-5.1.0.GA\server\default\deploy\jbossweb.sar\context.xml