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).
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.
Environment:
Windows Server 2012 R2
JRE 1.8.0_101
IBM WAS Liberty Core 8.5.5.5
IBM MFP 8.1
Apache Web server
We have set up the UAT with the above environment. We have deployed our application on the server, have deployed adapter for user authentication and a resource adapter to fetch the data.
When we invoke an adapter procedure without security (unprotected) the app is fetching the data. But when we try to invoke an adapter procedure with default scope or with a custom scope Instead of triggering the challenge handler, we are getting failure response with error status ‘201’ and error message ‘Created’.
Another observation is that, when the WLAuthorizationManager.ObtainAccessToken is invoked with default scope or with push.mobileclient, it is giving the same failure response with error status ‘201’ and error message ‘Created’. The same application works fine in the development environment.
When I try to obtain a token from postman using https://domain:port/mfp/api/az/v1/token and pass the scope, grant_type and the necessary authorization header, it is providing the valid response with token. But from the app when we try by obtain token it is given failure response.
Failure response
{"status":201,"statusText":"Created","responseText":"","responseHeaders":{"connection":"Keep-Alive","content-language":"en-US","content-length":"0","date":"Fri, 17 May 2019 05:42:45 GMT","keep-alive":"timeout=5, max=100","location":"/mfp/api/registration/clients/1e746550-e804-4ee7-88ba-b99896qqqqpwo","server":"Apache/2.4.39 (Win64) OpenSSL/1.1.1b","via":"1.1 ","x-powered-by":"Servlet/3.0"},"errorMsg":"Created","errorCode":"201"}
201 is not a response code that is expected from the /token endpoint. This is very likely coming from an intermediate element in your topology. You've mentioned about the Apache Web Server as part of the configuration - is this sending the 201 ?
Moreover, the actual response from the server shows "server":"Apache/2.4.39 (Win64) OpenSSL/1.1.1b"
So, here is what you can do
a. Try bypassing the web server and see if resolves the issue - in all likeliness, it should.
b. Validate the configuration settings of the Apache Web server to see why the 201 is being returned.
Late to the party, but for anyone that is still running into this error:
Install the following interim fix: 8.0.0.0-MFPF-IF202006151151
This solved the error for me. Seems to be a bug in MobileFirst, took me ages to find.
I have a Worklight 6.1.0.1 hybrid app that I'm running on iOS. The app uses adapter-based authentication. The app prepares the invocation data makes the following call when the Login button is clicked:
singleStepAuthRealmChallengeHandler.submitAdapterAuthentication(invocationData, {});
If the WL service is down, or if the mobile device has no network access, the invocation will timeout. I see the following in the Xcode console:
defaultOptions:onFailure Request timed out for http://myipaddress:10080/myapp/apps/services/../../invoke. Make sure the host address is available to the application (especially relevant for Android and iPhone apps).
How can I capture this timeout event, so that I can update the UI with a proper message?
Update May 23rd based on comments:
What is your exact flow?
You should first use WL.Client.connect({onSuccess: ..., onFailure:...});
If connection to the server is successful, you will enter the challenge handler. Otherwise, you will enter onFailure and there you can create the custom error handling.
Previous answer attempt:
The below is when trying to connect() to the Worklight Server.
If you want custom handling for when the client fails connecting to the server I believe you need to enable and use the option onConnectionFailure in initOptions.js:
var wlInitOptions =
// # The callback function to invoke in case application fails to connect to Worklight Server
//onConnectionFailure: function (){},
}
Otherwise, Worklight's default dialog will be displayed.
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.
With the OAuth 2.0 and encrypted access token changes I can't connect to FB chat anymore. The example on FB's chat document shows PHP on the server side, however I need to connect by getting the access_token from the JavaScript sdk.
I took out the sig and session_key parameters from my challenge response, and added the parameter for access_token, setting it to the access_token I get from the JavaScript sdk. I assume the access_token is correct because before Oct 1st it had pipes in it, and now it's encrypted without the pipe symbols. Also looking at my security settings, the xmpp_login permission is being set properly when I initially grant permissions.
No matter what I try my connection attempt fails.
Does anyone have working code where the access token comes from the JavaScript sdk in a browser rather than from the server side?
Got it: Make sure you're also using TLS. In the PHP code example: http://developers.facebook.com/docs/chat/ you'll see how this is handled if you search for $START_TLS