i am working on a MobileFirst application. It needs to be integrated with IBM security access manager. i have configured the login modules, realms and authentication configurations. On the code side, what should be done?.
Read the help for this product: http://www-01.ibm.com/support/docview.wss?uid=swg24034222
The integration package includes sample applications and adapter to
validate successful HTTP header or LTPA token integration, single
sign-on to backend data sources using Worklight Adapters, OAuth
authentication, context/risk-based access, Device Single Sign-On and
MobileFirst Platform Foundation generated Certificate Authentication.
The sample applications and challenge handlers are intended to be used
as references for developing your own IBM MobileFirst Platform
Foundation mobile application integration with IBM Security Access
Manager.
Related
we have working MobileFirst 6.3 javascript adapters on our app and authentication is based on the setActiveUser and getActiveUser of the WL.Server APIs.
Which is the equivalent in MobileFirst 8? I see that there is the UserAuthenticationSecurityCheck, but available only on java Adapters..
Thank you
In MobileFirst Foundation 8.0 authentication flows are implemented using security checks, and security checks are only Java adapters. There is no equivalent for this in JavaScript adapters for v8.0.
I recommend that you will read through the following topics to learn more about migrating to v8.0:
Authentication and security: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/
Migrating applications: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/upgrading/
I need to make some of my MFP 8 Adapters available to third-party (non-MobileFirst) clients. Is this possible in production using Confidential Clients? Thanks.
Yes. You can read more about the implementation in the following tutorial
https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/confidential-clients/
Clients that do not use the MobileFirst client SDK can also request protected resources, by acting as a confidential client.
I've seen that Azure App Service mobile apps can implement authentication for multiple identity providers via a single client SDK. If an app hosted on Azure App Service is using ASP.NET Core in the cloud, though, can its UWP or Windows Store client app also benefit from multiple identity providers via a single client SDK?
If yes, then how does that work? Does it use the same mobile client SDK?
If no, then how would I authenticate such a mobile client? Will I have to use individual provider SDKs?
I know ASP.NET Core is still prerelease, but I'm wondering:
What multi-provider authentication functionality is available from a mobile client now?
What such functionality is planned to be available when ASP.NET Core 1.0 is finally released?
What such functionality will likely be on the roadmap for the future?
Azure App Service provides authentication as a service. In other words, the client authenticates to the service, and the service passes on the authentication to you.
Underneath, the app service passes a number of authentication related app settings within environment variables that you can read via the normal method. The original JWT is also passed in via the X-ZUMO-AUTH header.
For your clients, probably the best way is to use the Azure Mobile Apps client SDKs - there are clients for .NET (Xamarin, UWP), JavaScript, iOS and Android. You don't need the data access functionality - just the client creation and login / loginAsync method calls.
For your server, take a look at the Authentication Overview for more information. You may also want to read some of the info in Chris Gillums blog for more technically details.
Application Server
AIX V7.1
WebSphere
Application Server V8.5.5.4
Java SDK V7.0.8
MobileFirst Platform Foundation 6.3
DB2 V10.1 client
Database Server
AIX V7.1
DB2 V10.1
We have a MobileFirst application that is our mobile front-end to an existing application. The existing application is a WebSphere application that provides RESTful web services. The MobileFirst application interfaces with the existing WebSphere application via a MobileFirst Adapter. The RESTful web service URLs are protected URLs and authentication is done using LDAP and a LTPA token is created. The LDAP is configured in WebSphere via the WAS console.
Our MobileFirst application works fine and can connect to and use the RESTful web services but only if the MobileFirst application is running in a separate WebSphere profile or on a separate WebSphere server. If we attempt to install the MobileFirst application into the same WebSphere profile as our existing WebSphere application that provides the RESTful web services, it breaks. The Mobile device authenticates with MobileFirst successfully and then calls the Adapter to invoke the RESTful web service call. However, the next Adapter invocation from the mobile device ends with a HTTP 401 error, which is an authorization error.
I'm speculating that after the Adapter authenticates with our existing WebSphere application that provides the web services that somehow this is overwriting the authentication that was done between the mobile device and MobileFirst.
My questions are as follows.
Can both the MobileFirst application and our existing WebSphere application that provides the RESTful web services run in the same WebSphere profile and share the LTPA token such that when the Mobile device authenticates with MobileFirst that it would also be authorized to execute the web servies running in the same WebSphere profile.
Is it advisable to run both applications in the same WebSphere profile or should they be running separate profiles or on separate servers.
Cost is a concern as we do not necessarily want the additional operational cost of adding a physically separate server just to run MobileFirst.
From an operational perspective, it is additional work to add and maintain multiple WAS profiles.
Ideally, we would really like to run both applications in the same WebSphere profile.
Here is a Google Drive link (no signin required) to the trace.log, SystemOut.log, SystemErr.log, and firebug-console.html
MobileFirst Trace log
The MobileFirst application was run in a browser using "Preview as Common Resources". I get the same result when using an actual Android or iOS device. The MobileFirst application WAR was run in the same WAS profile as the web services WAR that it was accessing through the adapter. This same code works successfully when the MobileFirst application WAR is running in a separate WAS profile or on a separate WAS server.
Please advise.
I have resolve the issue myself. This was a codebase that my team had inherited from another team.
What was happening was the mobile device was initiating a connection to MobileFirst running on WebSphere which creates a JSESSIONID cookie and a LTPA2Token cookie. Then an adapter was being called that invoked a HTTP call to a web service running in the same WebSphere profile. Calling the web service created new JSESSIONID and LTPA2Token cookies. These new cookies were being returned to the mobile device and JavaScript code on the mobile device was taking those new cookie values and then overwriting document.cookies, which wiped out the original cookies. Then when the mobile device attempted to connect with MobileFirst on a subsequent call, it's session was invalid and ended up getting a HTTP 401 error, which is an authorization error. So we attribute this problem to a poor implementation of our application.
I am building an iOS and Android Apps using Worklight Framework, the worklight server will be protected by IBM Security Access Manager (ISAM) SSO, and therefore the Apps can only be reaching the worklight server after passing the Security challenges. I've found some docs about this integration and it works as intended.
But the apps also offers some features that doesn't required login, in which the Security Manager shouldn't intercept the adapter request to worklight server. The only workaround that suggested by IBM is to create a URL mapping junction in ISAM that defines the URLs that can access by public, and those which shall not. for example /worklight/public and /worklight/secured
But the URL pattern for all worklight adapter are /worklight/invoke?adapter=ADAPTER_NAME, so do we have a way to create a customized URL for public and secured adapter, for example:
/worklight/public/invoke
/worklight/secued/invoke
EDIT 1: Worklight Version 6.0
Thanks in advance.
Please mention the version of Worklight you are using.
One way to achieve this is to create and deploy the adapters in two different projects. That way the context root of both the adapters will be different. So, you'll have URLs such as
/Project1/invoke?... and Project2/invoke?... which you can apply to your filters.