I am using IBM MobileFirst Studio Plugin 7.0 and was following the tutorials for adapter based authentication here Documentation.
I see that the isInternalUserID is not used to create the userIdentity object unlike the form base authenticator Dcumentation . Can it be used? Or is it specifially so that the code to create the userIDentity needs to be done in the adapter?
There are two parts to the answer:
a) When using a custom security test, "isInternalUserID" is used to identify a particular realm as the one that will be used for creating user identity. If a realm is marked with "isInternalUserID" it means that only this realm is used for user identification.
There must be exactly one such realm for every security configuration that is applied to a mobile or web resource.
b) Adapter based authentication allows the flexibility to develop custom authentication logic within a MobileFirst adapter. This is why you see that userIdentity is created and assigned with adapter logic ( unlike the form based sample).
However, you will note that the generated identity is still assigned to the realm , that is marked "isInternalUserId" in the security test.
More details:
Understanding predefined Worklight authentication realms and security tests
Security Tests
Implementing adapter-based authenticators
Related
How can i use MFP (8.0) adapter based authentication without installing mfp client sdk / libs.
Is it possible to make REST call to the adpater (login) directly from the client application (mobile) without the client sdk.
Updates:
I have tried confidential client option , but i need individual user details instead of pre-defined client id.
You can't make Adapter Based Authentication in your Client Application without MobileFirst SDK.
However this is possible only with unprotected adapter endpoint.
Security check adapters cannot be accessed via REST calls. You can protect your resources with scopes mapped to these securitychecks and they get invoked when the resources are accessed. At the client, uou handle the challenges that come from the securitychecks. This needs the MFP Client SDK to be in place. You cannot access the securitycheck adapters directly without MFP client SDK.
There are two ways for you to avoid invoking a securitycheck:
Do not mark the resource with any security. In this case default security scopes get applied. However you still need MFP client SDK to handle the OAuth handshakes.
The only other way to avoid invoking security check adapters is to explicitly mark your resources un-protected ( disable OAuth security for that resource). This will prevent any challenge answer mechanism and you can access the resource without MFP client SDK. Do note that your resources (via REST endpoints) will be open to attack - there will not be any security applied on it.
I'm looking for help with custom Principal used in custom LoginModule on Wildfly10/Jboss 7.
I would like to put some additional data into my custom principal connected with authorization as well as audit data such as sessionId gathered from HttpRequest in my custom LoginModule.
In EJB implementation i'm getting my custom principal object from sessionContext.getCallerPrincipal() and it works pretty well when user is authenticated by my LoginModule (where i produce desired principal object).
Problem starts when i turn off BASIC authentication on any webservice or when i'm using #RunAs implementation in my EJB call stack.
In case with authentication turned off im getting "anonymous" SimlePrincipal object from getCallerPrincipal() and SimplePrincipal with one role in case with #RunAs.
Is there any way to force Jboss to use my custom LoginModule or any other module
where i can produce my custom principal and put in into sessionContextCaller principal?
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.
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.
We are developing an application in Java with struts2. We have a default authentication mechanism (LDAP) for the web application.
We would like to enable a different authentication for a subset of the web app for some external users (Not on LDAP but from database table login/password) who have limited access.
I believe you can achieve this by some sort of custom Interceptor.You need to identity which part of the application you want that authentication and can place your custom interceptor based on your requirement.