I have an application running on JBoss 8.1 with JAAS form based login (j_security_check) and everything works fine.
My problem is:
1) the user logs out and is redirected on the login page
2) here a session timeout occurs (the user doesn't know this)
3) the user returns and logs in correctly
=> BAM: he is redirected with j_security_check (the URI ends with j_security_check), but the page is empty.
My guess is: JBoss doesn't know anymore the previously requested page, because the session timeout occurs and this information is lost. So JBoss doesn't know where to send the now logged in user and the page stays empty.
I found some posts but no real answer/solution for this problem.
Thanks for your help!
Related
I have a Java web application using JSP and servlet, it works fine, but some times when all users are try to login using correct username and password, the web app returns "servelet login" error with blank white page. i dont know why it happens, but when i restart the server it works fine for some days. please help me, i try googling but i didnt get anything.
screen shoot of my java webapp affter i try to login using correct username and password. the first page i.e login page UI loads perfectly, untile i click on login button
i try to login using correct and incorrect credential, in both case it returns servelet login blank page screen. i used apache tomcat server, mysql and windows server 2016
I have a web application currently deployed on Wildfly 22, using JSF 2.3 and OpenJDK 11.
I'm currently migrating the login page from j_security_check to a programmatically login, following BalusC example on this post:
Performing user authentication in Java EE / JSF using j_security_check
I'm not posting the login code, because it's exactly like BalusC post.
The login process is working just fine, except when the session-timeout expires on the login page. In other words, when the user requests a protected resource, the login page is presented. If the session expires before the login form is submitted a ViewExpiredException is thrown and an error is presented to the user.
I understand this is the expected behaviour, however it's not the desired situation for the end-user.
I managed to minimize this situation using OmniFaces's ViewExpiredExceptionHandler.
This way, when a ViewExpiredException is thrown, the OmniFaces handler will catch it and redirects to the current URL with the query string.
In other words, the user tries to login after the session expires and the login page is presented again to the user.
I managed to use the #{flash['org.omnifaces.view_expired'] eq true} so that a nice message is presented to the user, explaining that a timeout occurred.
Is there any way to workaround this situation, and performing a successful login even when the session expires, so that the user doesn't have to enter his credentials twice?
Thanks for your help!
Is there any way to workaround this situation, and performing a successful login even when the session expires, so that the user doesn't have to enter his credentials twice?
Yes, by using stateless JSF by setting transient attribute of <f:view> to true.
<f:view transient="true">
<h:form>
...
<h:commandButton ... action="#{requestScopedBean.login}" />
</h:form>
</f:view>
Do note that the backing bean must be #RequestScoped, not #ViewScoped or broader.
See also:
What is the usefulness of statelessness in JSF?
Handle ViewExpiredException in the background and restore form values
JSF without #ViewScoped
I have deployed the OIDC provider-keycloak in a k8s cluster and it is exposed as a load balancer.
I'm using this along with Istio to redirect back to my application after successful login in keycloak.
The application is accessible at https://<istio-ingressgateway-ip>/hello
When I hit https://<istio-ingressgateway-ip>/hello, it is correctly re-directing me to Keycloak login page at https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth
However, after entering the username and password for the user, I'm not able to get the redirection back to my application at https://<istio-ingressgateway-ip>/hello.
I think the user set up is correct as I'm successfully able to login to the keycloak user console at
http://<keycloak-ip>/auth/realms/<realm-name>/account
I have configured the below values as the 'valid redirect URIs' in keycloak client:
https://<istio-ingressgateway-ip>
https://<istio-ingressgateway-ip>/hello/oauth/callback
https://<istio-ingressgateway-ip>/*
https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth/oauth/callback
https://<keycloak-ip>/auth/realms/<realm-name>/protocol/openid-connect/auth
Can please someone let me know what is missing here for the redirection.
Assuming you are using Authservice for the authentication and that your configuration is correct. I had the same issue and when I looked at the logs from the authservice container in my pod, I got to know that authservice failed to obtain the access token in exchange with the authorization code. The issue, as stated by Ryan from Authservice was:
When the Authservice tried to gracefully shutdown the TLS connection, and the server on the other side did not participate fully in the graceful shutdown.
This issue now has been fixed, and you can build a new docker image from the master branch to be able to fix it. More details about the issue and its resolution can be found on this github issue.
If in case this is not the issue, then there could be a problem with the flow from keycloak, you can use OpenID debugger to get the authorization code and then you can use that code to get the access token. This will help you identify if there is an issue on keycloak part.
If your configurations are correct and the above fix doesn't solve your issue, you should consider creating an issue on github with the logs from your authservice container.
I am encountering a strange situation with MobileFirst 7.1 where users are occasionally unable to authenticate/login. The only indication that something is awry is a message in the console.log
[AUDIT ] CWWKS1100A: Authentication did not succeed for user ID . An invalid user ID or password was specified.
My custom login module uses com.worklight.core.auth.ext.LdapLoginModule (so to clarify I have a login module which authenticates using LDAP). Like I say everything seems to work most of the time but occasionally users end up in a situation where they are unable to authenticate. I suspect that it is probably related to the session in some way, but that is only a guess based on my investigation.
I have added some logging to my 'secret' adapter which prints the session state to the console log, and obviously this appears in the logs just before the failed authentication message above, but it is empty ie. the session contains nothing.The user is obviously trying to access a secure adapter at this point, and because they are not authenticated they end up at the login page (form based authentication I should say also).
Anyway, I noticed that although there appears to be no session data, the jsessionid is there and has not changed i.e. it does not change even if I refresh the browser. This may not be an issue in itself of course, but interestingly if I remove this entry and refresh my browser I am able to login successfully.
I am pretty sure that my handler code calls the relevant success/failure methods in the correct places but of course there is nothing to stop the user refreshing their browser, which causes them to be re-directed to the login page (the app has been developed using AngularJS so is effectively a single-page navigation model).
The only reproducible test I have been able to come up with is when I login to the MobileFirst console and then try to login to our MF 'desktopbrowser' app. I have read that this situation causes a session-related conflict, but as I say the occasional issue I am seeing is not caused by this (though it may be related).
So the problem seems to have been more related to the flow of logic in our application after successfully logging in, than any inherent issue with the MF Platform.
For example when a user refreshes the browser they are effectively still logged in, but because the app (based on logic we have developed) takes the user to the login page on refresh, the user is effectively re-logging in to the same session. If this failed every time it would of course have been easier to pinpoint but it does not. The solution was to force logout on refresh (when the app initialises), thus cleaning up any session data. In future iterations it may of course be better to re-establish the application based on the authenticated session after refresh, but at present that was a step too far.
Another example of this was post login if the subsequent adapter calls failed (e.g. we authenticate and then retrieve profile data from a database), then we were also not logging the successfully authenticated user out.
I have started maintain a number of websites that are all authenticated using openam SSO. However when one of our users sets a persistant cookie (DProPCookie) it doesn't always work.
Repro scenario is:
Login to openam, setting the persistant cookie
Restart browser (to clear session cookies)
Go to site A, user is logged in automatically because of persistant cookie
Go to site B, user is presented a login page (they should be automatically logged in).
After step 3, if I delete the iPlanetDirectoryPro cookie from my browser I can login to site B fine (using the persistant cookie). It seems that the iPlanetDirectoryPro cookie generated from Site A when the DProPCookie is set doesn't work on Site B.
Note that I have tried with various permutations of Site A and B and the scenario is the same in each case.
I'm quite new to openam so any hints as to how to debug this would be great or if I'm missing something obviously going wrong please do let me know.
Thanks in advance.
EDIT:
I have subsequently discovered that the iPlanetDirectoryPro cookie returned when authenticating using the DProPCookie isn't working. So thus has nothing to do with cross domain.
Login to openam, setting the persistant cookie
Restart browser (to clear session cookies)
Go to site A, user is logged in automatically because of persistant cookie
Delete all cookies except iPlanetDirectoryPro cookie
Refresh page - asked to login
If I repeat the test but with the iPlanetDirectoryPro cookie generated by a normal login then when I refresh the page, I automatically get authenticated. (I have changed the title of the question to reflect this).
FURTHER EDIT:
Turned up debugging - am seeing this exception in the logs:
IdName is :null
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
orgName is :xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity() from IdUtils Name: null Org: xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity: Got IdRepoException while getting Identity from IdUtils: Illegal universal identifier null.
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
isLockedOut:Exception :
java.lang.NullPointerException
at com.sun.identity.idm.server.IdCachedServicesImpl.search(IdCachedServicesImpl.java:585)
at com.sun.identity.idm.AMIdentityRepository.searchIdentities(AMIdentityRepository.java:296)
at com.sun.identity.authentication.service.AuthD.getIdentity(AuthD.java:1453)
at com.sun.identity.authentication.service.AMAccountLockout.isMemoryLockout(AMAccountLockout.java:297)
at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:281)
at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:264)
at com.sun.identity.authentication.service.AMLoginContext.processPCookieMode(AMLoginContext.java:1919)
at com.sun.identity.authentication.service.AMLoginContext.processIndexType(AMLoginContext.java:1846)
A quick scan through the openam code - it appears that we are not getting a username here in AMAccountLockout.java:264:
public boolean isLockedOut() {
// has this user been locked out.
String userDN = loginState.getUserToken();
return isLockedOut(userDN);
}
Persistent Cookie mode has changed in OpenAM ... DProCookie is actually not used anymore.
Posssibly you're running 'restricted token mode' AKA 'cookie anti-hijack mode' and CDCServlet does not issue a proper authentication assertion
Could be that you are running into https://bugster.forgerock.org/jira/browse/OPENAM-1002 ?
Also it could be a problem with your cookie domains, maybe site B redirects to a different domain where DProPCookie is not visible?
Ultimately we discovered that the problem was that the SSO cookie generated by the persistant cookie had no authention modules - and therefore the authentication level was set to Integer.MIN_VALUE;.
In our situation we made a slightly hacky fix to force this to be 0 instead, which fixes up the problem.
I presume the correct thing to do would be to either have a seperate authentication module for persistant cookie logins or to store the authenticating module in the SSO cookie generated by the Persistant cookie.