I am using IBM MobileFirst platform 7 to develop a hybrid application for one of my clients. I am using the below environment setting to protect the app so that on app launch when it connects to the MobileFirst server, app will receive a security challenge from the server.
<iphone bundleId="com.AppTest" version="1.0" securityTest="mobileTests">
The app handles the challenge by showing the login screen to the user. I am using adapter based authentication for the app. This is working fine.
Problem with the above setup: There is a 'New user sign-up' link in the login screen that redirect the user to a sign-up screen. On load of the user sign-up screen, app is invoking an adapter procedure to get some data. The adapter procedure invoked from the sign-up screen is not protected with any security test.
Even though the adapter procedure is unprotected, the above setup doesn't allow the app to invoke the procedure before a successful user authentication. Server is throwing a challenge back to the app when the user clicks on the registration link and he stays on the login screen.
Does MobileFirst authentication framework provide any option to explicitly bypass the security check for specific resources while using environment level protection? I have gone through the platform documentation and couldn't find any such options. If anyone faced a similar problem and resolved it, could you share your suggestions on handling this please. Thanks.
The adapter procedure invoked from the sign-up screen is not
protected with any security test.
Does that mean that the specific procedure has no securityTest assigned to it? If so, you can try setting it as securityTest="wl_unprotected". Even if not explicitly setting a securityTest, there still default security assigned internally. To disable that try the mentioned wl_unprotected suggestion.
Read more here: Understanding predefined Worklight authentication realms and security tests
Setting securityTest value to wl_unprotected means that the resource
will not be protected by any of Worklight platform security
mechanisms. This security test cannot be used to protect application
environments and event sources as they both require user and device
identities. Usually this security test is used to protect adapter
procedures that should be publicly accessible without any
authentication requirements.
Related
Hello Stack Community.
I'm looking for formal name of technology/technique that's being used in Microsoft Azure CLI and in Epic Games Desktop application, that is responsible for delegation of authentication from target application to browser, where you perform OpenID Connect authentication and brings you back to target application: CLI App or Desktop App, where you can proceed as logged in user by using authentication you gained via browser.
The steps would be:
you launch target app (CLI, desktop app)
login attempt lets you choose oAuth OIDC via Google or so
selecting it opens default browser, where you proceed with login
You gain auth inside app you started from (CLI, dektop app)
In classic OIDC process you gaining your token in same app/browser environment, while here authorization is expected in app A, token is gained in web browser and afterwards there is possibility to re-use it in completely different application.
I'm wondering is this some particular OIDC extension, usage of some particular grant flow or just some particular hacky way of sharing token across entities?
I found one online resource here but my investigation don't confirm starting of any redirection URL localhost server for toke possession.
I'd appreciate any help in my investigation.
WL.Client.InvokeProcedure is an internal API and used by Worklight Framework, however, you can call this API after connecting a device in Debug mode with Google Chrome. How can we restrict the access to WL.Client.invokeProcedure so that a user is not able to Exploit this call?
Steps to replicate (for Exploitation Only):
1. unpack an APK built by Worklight
2. Set the android:debuggable=true (also check how WL Adapters are being called in JS files)
3. Rebuild the APK
4. Install the APK in mobile
5. Start the Application and connect through Chrome://inspect
6. Authenticate as a "normal" user
7. Go to Developer Console
8. Invoke WL.Client.invokeProcedure for any adapter you are authenticated, but with unauthorized User Data
I think the test is a bit misleading since "you" as an attacker will have several prerequisites: have the technical skill of manipulate code, invoking code and know what is a "normal" user.
That said:
In the upcoming MobileFirst Platform v7.0 you will be able to obfuscate the code of a mobile app (iOS, Android and so on). You can also do this manually now.
Already now you can enable the Application Authenticity Protection feature as well as the webResourcesChecksumTest and webResourcesEncryption features. See the security element section in the Application Descriptor user documentation topic.
The above will add several layers of protection to your application, either preventing tampering with the application code, not allowing to use the app if its checksum has change and verify the application identity.
I have gone through IBM Worklight Authentication concepts. Now I have few questions.
1) Is there a practical use of Formbased authenticater ?
All the examples I have seen uses NonValidating Login module which doesn't really validates the credentials. So what if I want to use the Form based authenticator to check the credentials against the db ? Can you please point me to a real world example ?
2) If I choose custom security test for my application, I won't be get the wl_antiXSRFRealm enabled by default, what if I don't use it, is my app vulnerable to attacks ?
3) Read in one of the article "Therefore in case your security configuration is close to default security settings you might want to use webSecurityTest and mobileSecurityTest. "
It means, we are not going to ask the users to enter credentials ?
4) A practical scenario where Custom Login module & Custom Authenticator can be used ?
There is no connection between either Form-based authentication or adapter-based authentication and the non-validating login module. You could implement them by using non-validating, or by actually validating the user credentials...
Non-validating login module is used in the sample because we cannot supply you a back-end with the sample; the purpose of the sample is to show the implementation of the client-side.
In form-based, the form is returned by the server. In adapter-based and custom-based you are less restricted and can handle this in the client. Either way, you handle the authentication using a challenge handler.
Also, please read: Understanding predefined Worklight authentication realms and security tests.
If you use a custom security test, there is no such thing as "default". You determine which tests will be in it. Simply add it back.
The antiXSRFRealm has got nothing to do with user credentials and your login module.
It is mainly used for Desktop websites and not for mobile devices; if you want, add it back in your custom security test.
I've set my authenticationConfig.xml to work with LTPAAuthentication in this way:
It works well with application where i require LTPA Authentication.
But there are some apps deployed on the WL Console that not need any authentication, they just call adapters. From browser (PReview common resource) they work as well as before, but if i run them from my android i get those error on Logcat:
...................................... (all the login.html page)
It returns me the entire login.html page as it does with application that requires LTPA mobile test, here you can see the application-descriptor.xml that highlight no need of security tests:
Any suggestion?
EDIT: this is the adapter, it doesn't require security tests
So it looks like you have an adapter that you have protected using WASLTPA security that you want to be accessible by all devices regardless of whether or not they have been authenticated by the WASLTPARealm. I think the solution is to re-design how your security and adapters behave.
If you wish for an adapter to be called from an application that does not need to be authenticated, then don't protect the adapter using a security realm. If being logged into the WASLTPARealm is not a requirement for accessing the resources that this adapter is exposing, then there is no point in using the realm to protect it.
For the apps that do require login, you should separate the authentication logic from the adapter calls. You can still require the client to login in order to use the app and call adapters without having to protect the adapter with the security test. There are APIs to check if a user is logged in and to prompt them to login to a realm. You don't have to use the challenge sent back from adapter to prompt a login.
An adapter should be protected by a security test only if being logged into that realm defined by the security test is a requirement for using that adapter. From reading your post, it does not seem to be a requirement.
From browser (PReview common resource) they work as well as before, but if i run them from my android i get those error on Logcat
I have a strong feeling that in your browser you have an LTPA token which is why this is working from an app that hasn't logged in to the LTPA realm. Try clearing your cookies and trying to do this again to confirm.
I use Google Webtoolkit together with Phonegap to build a mobile app. My app is communicating over a REST APi with my Backend Server.
What I want to do is a user authentication, i.e., my app user should be able to signup and login. If a user closes the app and reopens it, he should be authenticated again if he has not logged out before.
Usually, with Spring Security you do the authentication on the server by calling the required methods. The client (browser) then contains some cookie information for a persistent login.
1. How can achieve this kind of authentication for my app?
2. Should I do the authentication as for a normal web site with the only difference that the authentication methods are called by the REST api methods?
3. Is there another way of doing the authentication for my mobile app?
I think user authentication for the mobile app will be the same as for a normal web-app.
The Spring backend will create a session once a user is authenticated. By default the user is authenticated for the duration of the specific session (until the user closes the browser/app).
Spring Security has a Remember-me functionality that is typically based on a Cookie approach and allows the user to be re-authenticated automatically..
I don't know if phonegap work with Cookies (see here for some pointers). I guess it depends on the plattform (if webview supports cookies).
May be this will help you I wrote an article that show how to adapt Spring Security to secure REST services.
You can check it in here : http://crazygui.wordpress.com/2014/08/29/secure-rest-services-using-spring-security/
I also posted a working example which shows how I did use that with GWT on GitHub.