I am migrating my app from MFP V7.1 to MFP V8.0. Earlier there used to be worklight.properties file in which we can modify the session timeout value. What is the idle session timeout for MFP V8.0 app and from where it can be configured?
In MobileFirst Foundation 8.0 there are no sessions... since you're based on the OAuth protocol. What you have is tokens. Tokens have expiration values... your connection to the server is invalidated once the token expiration has been reached. Read more about access tokens and token expiration in the Knowledge Center: http://www.ibm.com/support/knowledgecenter/SSHS8R_8.0.0/com.ibm.worklight.dev.doc/dev/c_oauth_security_tokens.html
Related
using mobilefirst client 8.0.0.00-20180817-042259
on WebSphere Application Server V8.5.5.8 Liberty
added a confidential client named Push
after initial setup of allowed scope,
it cannot be modified and deleted.
test, admin, push as predefined confidential client.
Is that case-sensitive?
Or a mobilefirst bug?
Or any other settings to edit the client?
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 am trying to use MobileFirst Server as a OAuth Server. The knowledge center provide detail step on how any external application can validate the token sent by Mobile client via MobileFirst Token validator end point. But not able to find proper documentation for request a new authorization token from mobile client from MFP Server.
In development environment we have a testtoken endpoint.
http://localhost:10080/OAuthExternalServer/authorization/v1/testtoken
{ "Authorization": "Bearer eyJqcG ......... }
How to get similar token from MFP production server on mobile client.
MFP Version: Server version: 7.1.0.00.20170330-0917
Thanks
With the OAuth security model, MFP server is your OAuth token provider. Upon completing the challenge server gives you an OAuth token. You need not do anything special in the ChallengeHandler for OAuth token. Refer to the samples here: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/7.1/authentication-security/
If you are looking to use OAUTH for authenticating an external resource , refer the steps here https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/7.0/authentication-security/using-mobilefirst-server-authenticate-external-resources/
Here is an example token validator which uses introspectionData to validate https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/protecting-external-resources/jtv/
Basically Introspection Endpoint can be invoked to validate the token provided by MFP server
General OAuth flow with 7.1 for a default flow can be referred here https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/7.0/authentication-security/authentication-concepts/oauth-based-security-model/ .
I know logout desn't work for Java adapter in Worklight 7.0, and found that it still doesn't work in Worklight 7.1. Is there any good work-around to discard an authenticated session?
You are not explaining what you're doing nor where you're doing it as well as did not provide a single line of code (you can use any service that hosts files to host your code)...
Therefore, I can only direct you to the following answers:
MobileFirst OAuth and Logout
MobileFirst OAuth Logout, cached OAuth indentity
I have two MFP v7 Servers running on Liberty Profile 8.5.5.3 and if I access the console via an HTTP Server (IHS), I always get the login screen even after a successful authentication.
I see this lines in the server logs:
[4/21/15 13:25:41:704 CDT] 000000a2
com.ibm.ws.security.token.internal.TokenManagerImpl I
CWWKS4001E: The security token cannot be validated. This can be for
the following reasons
1. The security token was generated on another server using different keys.
2. The token configuration or the security keys of the token service which created the token has been changed.
3. The token service which created the token is no longer available.
The plugin is expecting the JSESSIONID cookie to set the affinity, but it seems the cookie is never generated by the server.
I can get into the console if I set the same ltpa tokens on both servers, but that does not solve the original problem, which is that the affinity is not working.
Normal. The affinity is not working since there is no session affinity.
The MFP console doesn't create sessions because there is no need to keep information in session and so there is no session affinity and no JSESSIONID cookies. Every server can process every request even if the previous request was not processed by this server.
So for example the console can run on server and invoke a service that will run on another server.
All this means that for the console SSO is required. So you need to have the same LTPA keys on all servers.