My problem is as follows :
I have an application protected by a mobile security test involving a LDAP server. The corresponding realm is called LDAPrealm. I use the form-based authenticator + custom LDAP login module.
When the connection to the worklight server is lost and then re-established, I see that the current user is not authenticated in the LDAP realm anymore.
What I want is be able to re authenticate the user without having him enter credentials again.
However, since the user is still authenticated for other realms included by default in the mobile security test, the worklight server does not challenge the client again for credentials, which is causing j_security_check error when trying to submit credentials.
As a side note those credentials are stored in the encrypted json store for offline authentication and use of the app.
So my question is :
Is it possible to force the server to challenge the client again for this LDAPrealm and use submitLoginForm to re-log in?
More generally, is there a way to clear a user+device from all realms before trying to log in again?
Edit reasons : previous error was caused by a typo
In the case where the user first logs in online then loses connection then get connection again, calling
WL.Client.logout("LDAPRealm",{onSuccess:stealthed_relog});
and calling WL.Client.connect() later in stealthed_relog before sending credentials seems to wield the desired behaviour.
However, when the user logs in offline and then gets connection, when I try to use WL.Client.connect(), it says another instance of WL.Client.connect has already been called.
edit : for the log offline case, the application get challenged automatically shortly after that the connected event fires (cause of heartbeat? I do not really know), so you just have to use
login_clientside.submitLoginForm();
to successfully log in again.
If someone has a better way to implement auto-reconnecting in worklight with ldap server, feel free to post it and I'll unaccept my answer.
Related
I have a web application using glassfish and form authentication (j_security_check). All the passwords and usernames are stored in a javaDB (derby). I was able to log into the system while developing on the localhost and now that I deployed the app to AWS whenever I try to log in with a user (I have checked that the user actually exists in the DB), I always get the same error (that i normally get when entering wrong details) i.e. WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed.
Any ideas what it might be? I don't even know what info to provide since the issue doesn't even throw an exception or something. thanks
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 a test application that accesses two Adapters:
A JavaScript adapter protected by a SecurityTest referencing a realm
A Java adapter with a method protected by an OAuth scope corresponding to that same realm.
If I follow this sequence everything works as expected:
Attempt to access the JS adapter, I get challenged, authenticate, get data.
WL.Client.isUserAuthenticated() and WL.Client.getUserInfo() now behave as expected
Logout using WL.Client.logout()
WL.Client.isUserAuthenticated() now shows I'm not authenticated
A second attempt to access the JS adapter causes another Challenge, as expeccted.
However, with the Java Adapter logout() seems not to behave as expected.
Starting with no session, attempt to access the Java adapter, the challenge happens as expected and I get to my data
I can now access the JS adapter without further challenge and the WL.Client.getUserInfo() calls gives the expected results.
WL.Client.logout() appears to work, in that WL.Client.isUserAuthenticated() now shows I'm not authenticated
But a call to the Java adapter still works without further challenge
A call to the JS adapter does result in a challenge
If I'm running in my browser simulator environment I can destroy the OAuth session by using this command:
localStorage.removeItem("com.worklight.oauth.idtoken")
The question is:
Should the WL.Client.logout() method have destroyed the OAuth session? If not what API should I be using?
With OAuth, logout 'works' differently. See the following user documentation topic (search for "logout"): http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/dev/c_oauth_security_model.html?lang=en
The login/logout API:
The WLClient login/logout API enables a user to
log in to and log out of a specific realm, by updating the server side
security state. However, in the new OAuth-based security model,
security credentials are also kept in the access token on the client
side. The result is that using this API will cause an inconsistent
state, for example, in which the client is logged out of a realm on
the server side but still holds a valid token for that realm on the
client side. To solve this inconsistency, it is recommended to
re-obtain the access token, by using the
obtainAuthorizationHeaderForScope method, after successful login or
logout.
For example, consider a client that passed the security checks for
Realm1 and Realm2, and later calls logout(Realm2). In this case, the
access token on the client would still contain the security
credentials for both Realm1 and Realm2, and the client could use this
token to access protected resources. To refresh the token, that is, to
obtain a token for Realm1 only, the client calls
obtainAuthorizationHeaderForScope without the logged out realm Realm2.
In JavaScript the equivalent call is:
WLAuthorizationManager.obtainAuthorizationHeader("SomeRealm")
While debugging, we observe following behavior:
1) When trying to get encryption key from server then error on both (iOS or Android) platform
response [https://xxxx.xxxx.com:443/worklight/apps/services/random]
success: Exception thrown by application class
'com.ibm.ws.webcontainer.session.impl.HttpSessionContextImpl.checkSecurity():685'
SESN0008E: A user authenticated as anonymous has
attempted to access a session owned by user:NewRealm/CN=test
user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
2) When trying to read a stored value error on android is [Logcat]
Android Message: Uncaught 9 at
file:///data/data/com.xxxx.xxxxapp/files/www/default/wlclient/js/encryptedcache.js:63
Where try to call WL.EncryptedCache.read
Worklight version used is 5.0.5 Consumer Edition (with Oracle 11i) on
Windows 2008 R2
WebSphere Liberty profile
Worklight server is sitting behind IBM Datapower XI52. All SSL calls to the server are going via DP.
Authenticator - WebSphereFormBasedAuthenticator & LoginModule - WASLTPAModule
The following is not really an answer, since I'm not familiar with authentication (LTPA, FormBasedAuth, Data Power, etc.)... just a couple of comments that could help you debug/isolate the issue.
Looks like a problem with authentication:
A user authenticated as anonymous has attempted to access a session
owned by user:NewRealm/CN=test user,OU=Temporary
Users,OU=Acc,DC=xxxx,DC=com.
Not with the Encrypted Offline Cache (EOC).
EOC will try to get a random token calling the following function:
WL.EncryptedCache.secureRandom(function (data) {
console.log(data);
});
It should output something like this:
response [/apps/services/random] success: 9053bdcfd902aac3dfb59a9874c9cf55223b7d17
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view the functions source code typing the following in a JS console:
WL.EncryptedCache.secureRandom
If you're using Google Chrome developer tools there's a checkbox for Log XMLHttpRequests when you click on the gear icon > General > Console.
You can also try to request the URL directly. Assuming the host is localhost, port is 10080 and project name is wlproj:
http://localhost:10080/wlproj/apps/services/random
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view HTTP traffic with Wireshark or Charles Proxy.
I imagine this will fix the EOC issue for you, if you don't mind generating the random token locally (less security, AFAIK):
WL.EncryptedCache.secureRandom = function(callback){callback(Math.random()+"")}
For example:
Notice it never goes to the server, everything is done locally.
A user authenticated as anonymous has attempted to access a session owned by user:NewRealm/CN=test user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
This usually means that there is a conflict with the session sent by the user (the session cookie) belongs to a user (in this case), but the LTPA token sent as a cookie was not sent or was not valid. There could be a few causes of this. This best way is to do a trace between datapower and the worklight server to make sure an LTPA token is even being sent to the worklight server. If it is, verify all of the LTPA requirements are met (synchronized time, same private key on both machines).
I'm using openDJ LDAP server for authentication process of a Java based project using JNDI.
Most of the other things like password expired, invalid credentials can be handled using exceptions. (using the understandable message in exception, or using the error codes in some occasions)
ds-cfg-force-change-on-add and ds-cfg-force-change-on-reset attributes are set to true in the password policy.
But when a newly created user logs in or, when a user logs in after a password reset by admin no exceptions occur.
Can somebody tell me how to handle this.
One alternative in this case is the password policy request and response controls (example) defined in draft-behera-ldap-password-policy, supported by OpenDJ LDAP SDK and other SDKs. You pass the request control to the directory server, and you get back a response control.
The response control indicates whether the password needs to be changed, why a requested password modification could not complete, how much time remains before expiration, etc.