Do we need to call WL.Client.Login API before submitLoginForm in MobileFIrst 7.1.0 while using Formbasedauthentication (LoginModule = LDAP).
IBM documentation does not mention it but we found that if we do not call it MobileFirst Server does not send any Challenge.But we call that before submitLoginForm we receive all challenge handler and got authenticated from LDAP.
Please Advice.
Yes.
submitLoginForm() is the step where the client side code ( challengehandler) sends the credentials to the server. This is in case of Form based login.
The challenge will come from the server as a result of the application connecting to the server by:
WL.Client.connect(). In this case, if the application is protected, server throws the challenge.
WL.Client.login(realmName). If this is a custom realm, the server sends a challenge to be handled.
Invoking a protected resource using WLResourceRequest. The server responds with a challenge.
When user enters wrong credentials to an earlier challenge
When the challenge comes, you handle it in the challengehandler. The handleChallenge flow in the client ends with the client submitting the credentials in the login form and sending it to the server using the API - submitLoginForm().
Related
I have an application that I need to do the authentication to an IDP (Azure) and if the authentication fails I want that the IDP to send back a response to my application that user is not authorise .the issue is that IDPs are not sending any information regarding the authentication failed and is just remaining on login screen.
Any ideas?
Best regards,
Mircea
Regardless of the SSO protocol used, Azure AD will always return an error code, message and debugging information.
If that's not the case, then Collect a network trace with Fiddler and post the results here minus any confidential information for additional debugging.
Optionally, you may try to Test SAML-based single sign-on from the Azure Portal to verify your application correct configuration.
Most likely it is an issue with the Redirect URI being used in the application for the event when user is not found on the IDP (Azure AD). This seems to quite similar to the following issue: Redirect not working for SAML login, php-saml with Azure Active Directory
I have two questions :
1- Does the MobileFirst ver 7.1.0 provides encrypt functionality on the client side and decryption on the server side?
2- I need to pass username/pswd to the database through an adapter call. From client when I call adapter and pass these credentials it goes as a query string. How can I hide these while send it to server-side adapter?
Does every mobile user have his/her own username password for the database? If so this is not ideal design. The database credentials must be held in the adapter's xml and the user must be authenticated to MobileFirst using security tests and login & authentication modules.
If you still go by your original design, you can use Java adapters to accept credentials from the user through the payload of the call rather than query parameters. See https://www.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.dev.doc/devref/t_impl_java_adapter_JAXRS.html
Having done this, make all your calls over HTTPS for the traffic to be encrypted during transit.
I'd like to know if each time my application runs I need to get the token and pass it to the server, or if it's only necessary once to register the application. Thanks a lot.
You need a token to register the GCM(push notification) to the Google Server. Then this token is passed and used in the server to send subsequent notification. This token should be persisted by the server so that it can be used to make API calls to the Google server. With this approach, your server and the Android device do not need to create a persistent connection and the responsibility of queuing and relaying messages is all handled by Google's servers.
For more information visit the Registering Client Apps and also check this documentation.
In what seems like an elementary scenario, calling a GET method in my OAuth2/OWIN-protected server prevents the server from receiving the Windows identity on subsequent POSTS to the /token endpoint. What am I doing wrong?
This is a Web API service that includes an embedded OAuth2 authorization server and Microsoft's OWIN pipeline.
The authorization server provider inherits from OAuthAuthorizationServerProvider, and is installed in my Startup class. It overrides both GrantResourceOwnerCredentials (for username/password authentication) and GrantClientCredentials (for the client_credentials grant_type).
Here's the problem. If I configure the service for Windows authentication the following ensues.
Client POSTS to my /token endpoint to get a token.
Client's Windows identity arrives at the server in the GrantClientCredentials method's context parameter (specifically, context.Request.User). I can give him an appropriate token using context.Validated(id), where id is a ClaimsIdentity appropriate to his credentials.
Let's say client even POSTS again to get another token. Again, his credentials come to the server in context.Request.User. All is well.
Client does a GET to my API endpoint, including the token.
Server can inspect the claims in the token. All is still well.
Either the same client or a different client POSTs to get another token.
This time, context.Request.User arrives as null. PROBLEM!!!
If I restart the server, everything is set right. Restarting the browser does not help.
These symptoms happen whether running with IIS Express or real IIS.
The problem exists only for Windows authentication. When Anonymous authentication is turned on and a username/password duo passed, the credentials arrive safely in step 7.
FWIW, I have not yet programmed anything pertaining to a client_id or "secret". Still working on figuring that part out. If that's the problem, I'd appreciate help in how to issue a client_id and secret.
I have a combination Web API and MVC application that is secured using Azure ACS, Windows Identity and passive redirects. This works well. Now I am adding a mobile application using PhoneGap that makes calls to the existing application's API. I having trouble figuring out how to implement authentication on the mobile client. I've got it mostly working, but I can't get the token to client due to the Return URL setting in ACS. The scenario is:
Mobile client sends get request to API
API responds with 401 if user is unauthorized
Client redirects to ACS login page and user authenticates
Token is sent to the Return URL which is the application running on a web server
For example, if I'm running the client app on localhost:63327, the token is sent to localhost:58392 because that's what is set as the return URL in the ACS configuration.
How do I get the token to my mobile client?
I see that people did not really understood your question.
This solution might work.
In a nutshell, is to add a new protocol to get the authentication token from the server to the app client.
PG App calls a web method registering a request to Auth:
POST BeginGethAuthToken
id = pickup Guid
pswd = pickup Password
BeginGetAuthToken can be a web method in your login page.
Server associates the pickup guid with the pickup password
PG Apps start the authentication flow by opening the log-in page using the InAppBroser
mywebapp.com/AppLogin.aspx?id={pickup guid}
The pickup guid is set as a cookie for your webapp domain.
User completes the authentication using the InAppBrowser.
AppLogin.aspx on successful authentication associates the pickup guid with the authentication tokens and ask the user to close the browser to go back to the app
the PG App picks up the authentication token by providing the pickup password.
note that for security the server needs to add expiration policies of pickup guids such that only one app can use a guid at a time and restart the process in case of collisions.
You effectively need to pre-authenticate your client. See http://blog.siliconvalve.com/2013/06/25/protect-your-asp-net-web-api-using-azure-acs-service-identities/