We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".
Related
My current setup is like this. The entire project was built using the official docs here - https://identityserver4.readthedocs.io/en/latest/
API Server
Auth Server with local login, google login and github login
Console based c# client
JS based client
MVC based client.
(all of it, as described in the official docs)
Locally, all of them work beautifully. Able to login, access api endpoints, logout, redirect, the whole thing works smooth.
I have deployed all 5 of them to five different azure web apps. They all have the standard xyz.azurewebsites.net domains ready to use. Now, I have run into some problems.
the console C# client is able to talk to the deployed auth server, collect token using a local account on the auth server and make calls to the deployed API server. Based on this, I assume that both the api server and the auth server working hand in hand, as they should.
Problem #1 - the JS client keeps saying
'The login is blocked because of CORS Missing Allow Origin '
Problem #2 - the MVC client loads the auth server, and then the auth server gives me this error.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Note : I have set the CORS policy on the auth server, both these clients, under client definition as follows. I am not too concerned about keeping the auth server open, so dont mind if any and every domain can call the auth server.
AllowedCorsOrigins = { "*.*" },
Also Note : I have set the URLS in the code before deployment. all loclahost:port number lines have been replaced correctly with the corresponding now published URLs.
So, what am I missing out here?
Update 1
I was able to solve the CORS issue. Have posted a answer here on another question.
Not able to enable CORS for identity server 4 in asp.net core
Update 2
So, now, both the JS client and the MVC client, are giving identical errors.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Update 3
I have opened an issue which has log details.
https://github.com/IdentityServer/IdentityServer4/issues/4691
I am not sure if this counts as an answer, but posting for my own question, as it might might help others. Also, this is only a guess at this point.
I found out that the redirects were permanently stored in the database I used with EF migrations. That mean, local in memory redirects were being overwritten anyway by the database stored migrations. I believe this is the issue.
I also realized that the console app is working fine for it does not depend on redirect URLs where as the JS and MVC based clients dont work because they do depend on redirect URLs.
At this point, the best thing to do and for you (if you used EF migrations to store your auth server configuration) on database would be start over and switch to in memory only. Alternatively, you can try and update the database to suit your deployment requirements.
Ultimately, I believe, unless it is absolutely necessary, keep the auth server config (like redirects and CORS settings) in memory as they dont take up much value and are rarely changed.
I'm using Glassfish 4 as a server with an AngularJS app as a client. Glassfish is exposing a REST API via JAX-RS (Jersey). I'm using Basic Authentication over an HTTPS connection. I have my own login form and am setting the Authorization header in my REST requests via JavaScript. My issue is that if I use normal web.xml based permissions (<auth-constraint> inside <security-constraint>), the responses come back with 401 with a WWW-Authenticate header (if the credentials are bad). This forces the browser to do the Basic Authentication dialog instead of my own and it appears there is no viable cross browser work around available on the browser side to stop it. So I need to somehow suppress the 401/WWW-Authenticate response.
I stopped using the web.xml based permissions, because it seems it is the Servlet level that is doing the 401 stuff. I was able to get Jersey authentication working with a filter and turning on the "RolesAllowedDynamicFeature" feature (in a matter similar to Glassfish #RolesAllowed with custom SecurityContext). That seems to work great and returns 403 for bad credentials (and thus no browser dialog). However, when I call my EJB's, they do not see the custom security context and the user I have set, so I get permission exceptions. If it matters: the EJB's are in a jar, the Jersey stuff is in a war, and both of them and bundled together in an ear. From what I can gather the only way to have the EJB's properly process credentials is to use the web.xml stuff.
I seemed to have painted myself into a corner and do not see how to make this work. Perhaps I can back out and return to using web.xml based permissions and somehow filter the servlet responses to not return 401/WWW-Authenticate? If so I could not find out how to do that. Or is there some way I can set EJB's security context? Or something else entirely? I wouldn't think using AngularJS with GlassFish and a REST API and Basic Authentication would be very unique, how does anyone do this?
Since posting this question I have found info on implementing a Servlet filter and using that to try to change the 401 response to a different status code. However, the filter never gains control if you have <auth-constraint> in your web.xml and the request is not authorized, so that did not help me. I still could not prevent the 401 responses.
But now I think I finally found the answer. I removed the <auth-constraint> tag from web.xml. I changed the Servlet filter to now extract the AUTHENTICATION_HEADER on its own and decode it (via javax.xml.bind.DatatypeConverter). Next I call HttpServletRequest.login (on the request object) with the decoded username and password. I catch the ServletException if the username/password combination is bad and use HttpServletResponse.sendError to send SC_FORBIDDEN. If I have a good login I call doFilter to continue on with processing of the request, and call HttpServletRequest.logout when it returns.
If I do this in combination with RolesAllowedDynamicFeature and annotations on the Jersey routines everything seems to work including calls to EJB's with their own security annotations.
Side note: before settling on HttpServletRequest.login I had tried to use HttpServletRequest.authenticate followed by checking the returned boolean, but when you gain control in that case the response has already been committed to be 401 and you cannot change it. I even tried passing a HttpServletResponseWrapper to authenticate to stop the commit from happening, but authenticate seems to get the response object through some other means, it seems to ignore the one you pass it (I even tried passed null and it didn't even notice).
I have been trying to resolve this for some time now. I tried googling for this problem but didn't manage to find anything. All the questions I found were about replaying already recorded HTTPS requests.
So, I need to record HTTPS requests on a site protected with simple authentication (the pop-up window asking for username and password).
And this is where I get stuck. I enter correct login details and confirm it, nothing happens and in a second i get prompted to enter login details again, no error message nothing. When I press ESC I get 401 UNAUTHORIZED error.
Basically the site is acting as if the login details were incorrect when in fact I tried the same login details without Jmeter's proxy and the server accepted it.
What I tried:
1) Logging into this site without JMeter's proxy - works without problem
2) Recording different HTTPS site with JMeter's proxy - I tried my email and that works correctly as well
I should also mention that I am behind a company proxy, but I tried it at home and the result was same.
As for JMeter configuration, I am using everything on default having:
Thread Group
HTTP Cache Manager
HTTP Cookie Manager
HTTP Request Defaults
Recording Controller
HTTP(S) Test Script Recorder
Guessing the Thread Group doesn't really matter since I don't run any tests, only recording.
Additional Details:
Server:IIS
Logging into sharepoint website
EDIT:
Forgot to mention I tried already Blazemeter Extension, but when i try to record the logging session, it just freezes. Website hangs on trying to contact Blazemeter Cloud and Blazemeter plugin freezes, making it imposssible to stop recording and having to restart whole browser.
Also just noticed that when I am already logged in and try to access the site it records it without any issue. So it's only the login which is problematic for some reason.
JMeter removes cookies and authorization headers while recording.
You can use JMeter Chrome Extension as an alternate way of recording your test scenario.
In order to properly replay the recorded script you'll need to add HTTP Authorization Manager to it .
Sharepoint can have different authentication types, i.e.
Basic HTTP Authentication
Windows Integrated Authentication (NTLM)
Kerberos
See Windows Authentication with Apache JMeter guide to learn how to bypass each authentication challenge in your JMeter test.
So I was able to finally resolve this. The issue lied in sharepoint authentication. I was logged in a domain with my personal account, but was trying to access the sharepoint using a different account.
Sharepoint ignored the login details I was prompted to enter and used mw domain credentials instead. So the answer for me was to access the sharepoint website while being logged into domain(windows) with the same account.
I am migrating from grails 2.2.2 to grails 2.3.4 to avoid a bug in 2.2.2 where the text value in the spring security property messages where not displaying, but I am running into all sorts of issues. Stuff that worked before, now it does not.
PROBLEM
When I run the grails app, the initial default page is index.gsp which is standard functionality but after installing and configuring the spring security core, spring security ldap, and spring securiy ui plugins I would like to make the /login/auth my default page.
In the previous release, I had it done via the UrlMappings.groovy config file by simply commenting, replacing or deleting this line
"/"(view:"/index")
for this one
"/"(view:"/login/auth")
My Config.groovy is set so that if the authentication is successfull to take me to the home page
grails.plugin.springsecurity.userLookup.userDomainClassName = 'security.Person'
grails.plugin.springsecurity.userLookup.authorityJoinClassName = 'security.PersonAuthority'
grails.plugin.springsecurity.authority.className = 'security.Authority'
grails.plugin.springsecurity.requestMap.className = 'security.Requestmap'
grails.plugin.springsecurity.securityConfigType = 'Requestmap'
grails.plugin.springsecurity.successHandler.defaultTargetUrl = '/home/'
and my Requestmap entries in the Bootstrap (if they are of any importance for this issue are as follows):
for (String url in [
'/', '/index', '/index.gsp', '/**/favicon.ico',
'/**/js/**', '/**/css/**', '/**/images/**',
'/login', '/login.*', '/login/*',
'/logout', '/logout.*', '/logout/*']) {
new Requestmap(url: url, configAttribute: 'permitAll').save()
}
new Requestmap(url: '/home/*', configAttribute: 'IS_AUTHENTICATED_FULLY').save()
It turns that when i do that... Eureka the login/auth comes as soon as the application is started but when I put the correct authentication credentials it does not seem to authenticate, it does does a 'slight little flicker' and it shows itself again.
However, If I delete this line
"/"(view:"/login/auth")
and put this one back in
"/"(view:"/index")
and then when I restart the application I manually to login/auth and put the correct credentials then it correctly takes me to the home page.
QUESTIONS
Did I miss any config setting anywhere that would make the login/auth the first page (but also allowing me to authenticate)?
I am not sure if this should be a separate posted question, but now by design the login page it's part of the plugin, before it was generated by and part of my code and I could style at my will. Do I have to copy paste the LoginController and the Auth.gsp in my app in order to customize the view or is there a better preferred way?
Thanks in advance.
The authentication mechanism in Spring Security works by keeping track of a referral URL when the login page is shown. And then redirecting to this page on a successful login. If you want the login page to be the first page people see just make the root view require authentication. I'm assuming most, if not all, of your application requires authentication. If this is the case, you don't need to make the login page the root view. Assuming everything under /home/* is locked down then Spring Security will detect that and immediately redirect to the login page when any of the secured pages are requested.
Long story short, you're making it harder than it needs to be.
As to your second question, I do believe you just need to create your own versions of those files in your app to customize them.
Hey I'm not pretty sure about your problem but you can try making the default login url /login/auth by
grails.plugin.springsecurity.auth.loginFormUrl = '/login/auth'
I have a webpage in a Liferay 5.2.3 site, in order to view this page the user shoulde be logged in.
i tried JMeter for stress testing but i stopped after i had this issue here ("invalid authentication token"). What other tool i could use to do stress test without facing the authentication issue (with example of script if its available).
I had the same problem. I managed to log in and then when sending POST requests to the server I only received 403. What I have done is that I set the auth.token.check.enabled to false in the portal-ext.properties.
auth.token.check.enabled=false
But be careful. The Portal Authentication Token was implemented to prevent Cross Site Request forgery, as explained here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
On a production environment set the property back to true.
More about that on the liferay site: http://www.liferay.com/community/wiki/-/wiki/Main/Authentication+Token
Well I'm not sure but you could try Grinder, it supports jython as scripting language, although i dont have a working script example at the moment.
You can use JMeter but you have to use its proxy to record your actions (login included).
Please see JMeter proxy step by step