Click here to Skip to main content
15,901,505 members
Articles / Security
Tip/Trick

Access REST Resources Secured By UAG from Mobile Device

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
21 Jun 2013CPOL3 min read 9K   85   2  
If you're trying to integrate with UAG from a mobile device, this tip is for you!

Introduction

If you've ever developed a mobile application or are in the process of developing one, then it's probably only a matter of time before you need to access web resources for data your app needs. For public web resources, this is a snap but what about secured resources? I found myself in this exact scenario. I was building an iPad application in C# compiled via MonoTouch. The resources I needed access to had SSO infrastructure setup with UAG. I attempted to integrate successfully with UAG searching the ends of the internet, talked with so-called UAG experts, etc. and no luck... If you're trying to integrate with UAG from a mobile device, this tip is for you!

Background

In my search to integrate with UAG to access our Web API, I first tried setting our IIS site for Windows Authentication per what the UAG expert indicated. Interestingly enough, I got this working quickly when accessing the Web API hosted on my developer machines. Later on, I came to find out that the development machines using Windows 7 were using NTLM V1. When I tried this pointing to our test servers running Windows Server 2008, it didn't work and found out that they used NTLM V2 and at that time Xamarin MonoTouch did not support NTML V2. This forced a switch to forms authentication in IIS and have a UAG login page fronting the secured resources which in our case was a Web API. No problem, right? Ugh, I could not find a working example anywhere for this, nor did I get any usable guidance from the UAG "expert".

Using the Code

Since we're talking about authentication through network messaging, there's no good way to just pick up the code and use it "as-is" (unless of course your UAG is configured exactly as mine was, good luck with that). Nor is there a screen shot or demo app that can be readily supplied because the login form and web resources will be unique to your environment. That said, the following is a list of steps you should go through to get the code working for your environment:

  1. Customize UAGCustomLoginPage.cs to align with your UAG login form by inspecting the form (i.e. View Source)
    1. Customize the GetFormDataAsStringFormat method to match the input fields including hidden fields in the login form
    2. Customize the TryParseLoginHtmlForSubmitFormUri method to align with how the form is submitted
  2. Customize UAGProxy.cs as follows:
    1. Customize the IsUriSecuredWithUAG method to expect the appropriate page name (defaulted to "/login.asp")
  3. Call SSOProxyFactory.Create with the URL to the login page
  4. For the returned object, call Login with the user name and password

During step #3 & #4, you may get lucky and it just works. However, you are likely to have to troubleshoot as your UAG environment may have some subtle differences. The recommended way to troubleshoot is:

  1. Step through the code to see where issues are
  2. Use a tool like Fiddler to see how end to end process works when just using a browser. You can compare that with what you are seeing happen in your code and adjust the code to match the process UAG and your browser is doing.

NOTE: You can do all your troubleshooting using desktop, no need for mobile devices yet. After you get things working on desktop, this same code can then be compiled via Xamarin MonoTouch, etc. to login programmatically without showing the web pages to the user.

Lastly, once you're able to get through the authentication process, you have all the cookie header information available on the ISSOProxy interface. Use those cookie/header values when submitting requests to your Web API (or other resource requests).

Points of Interest

Lastly, once you're able to get through the authentication process, you have all the cookie header information available on the ISSOProxy interface. Use those cookie/header values when submitting requests to your Web API (or other resource requests).

History

  • 21st June, 2013: Initial version

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
United States United States
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
-- There are no messages in this forum --