Forum Discussion

xavier_fabre_16's avatar
xavier_fabre_16
Icon for Nimbostratus rankNimbostratus
Sep 05, 2014

F5 APM and external mobile application log in

Hi everybody,

 

I'm a beginner and i start looking for solutions to create a connection between an IOS and Android and our F5 APM module.

 

So far we're using mobile web application instead of mobile native application. In that case it's easier, we're using the native logon F5 form to establish a connection between the mobile browser (any browser in fact) from internet to our web mobile site in our Intranet.

 

The idea 'll be to use the same mecanism but from our native apps. I already know that it's possible to use an external logon form (src : [https://devcentral.f5.com/questions/how-to-use-apm-external-logon-pages] ), i guess we could use something like that in our case. The mobile app will send the connection data with an http post request like the form to implement on the example before.

 

If anybody has implemented this kind of solutions using F5 APM i would be very pleased to know how it's possible.

 

Thanks,

 

Xavier.

 

android
BIG-IP Access Policy Manager (APM)
ios
security
  • xavier_fabre_16's avatar
    xavier_fabre_16
    Icon for Nimbostratus rankNimbostratus
    Sep 29, 2014

    Hi, after 10 days working on something else i started looking for an answer again. We still have some problems accessing our web services from a mobile device (internet) to our Sharepoint website (intranet) using F5 BigIP APM but at least we succeed to connect a user from internet to the sharepoint intranet site. To do this we access the my.policy form from the mobile application.

     

    It needs 3 steps to do this :

     

    • first you need to establish a connection to the form, to do that you just have to make an http request (get) to your entry point (dns, page, whatever redirect you to the F5 form). This step is necessary in my case because i can't send post data directly to the F5 form it redirects me directly to the logout page ... Maybe it's because something is not set correctly on my F5 params.

       

    • then you can see on your APM that you created a F5 session (not authentificated), then you can do another httprequest to your F5 form but you need to use the same object (same session). You have 3 parameters to use : username, password and vhost (an hidden input field in the F5 form with 'standard' as default value). In my case after this, it worked i was authenticated on my sharepoint. To send the data to the F5 form we use REST (username=X&password=y&vhost=standard)

       

    • last step, to access your pages / webservices you have to use the same session (in our case the same object). We're looking for another solution with a cookie stored on the mobile device instead of keeping the session object always open ...

       

    Our solution works but we still have problem accessing some webservices (GET is working but not PUT and POST webservices). It might be another problem (sharepoint configuration, or something wrong in our global architecture).

     

    If anybody else faces this webservices problem or need additionnal informations about what we did answer this post :)

     

  • xavier_fabre_16's avatar
    xavier_fabre_16
    Icon for Nimbostratus rankNimbostratus
    Sep 08, 2014

    Hi Kevin, thx for your answer. I understand what you mean, we'll start working with your idea. As soon as i can i will let you know how we figured out this thing.

     

    Regards,

     

    Xavier.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Sep 05, 2014

    The most important thing to understand here is that APM's user interface is HTTP-based. There are certainly ways around that fact, but the standard interaction is HTTP. Therefore to consume an APM (form) logon process with a native mobile app, that app will have to talk HTTP to APM. The first thing I'd do is take a capture of the client side logon process to see what that looks like. At a minimum your native app should be able to follow HTTP redirects and consume HTTP cookies. You can get around the redirects, but you definitely need to be able to consume and use the cookie if you want to maintain any sort of statefulness.