Bridging the Gap between the internal and external could - RSA Access Manager to protect resources on Google app Engine

Here at RSA, one of the areas of constant probing is the idea of using existing RSA applications to bridge the gap between internal infrastructure of an enterprise and its extension on an external cloud. With a long weekend at hand, I worked on this hobby project. This post details ways to seamlessly protect the applications that you have moved to an external cloud with an existing RSA Access Manager installation.
The only interesting fact is that Google App engine is Platform-as-a-service (as opposed to Amazon EC2 which is Infrastructure-as-a-service).
Here is a deployment diagram and the various components involved. As shown in the diagram, the identities of the user rests in a LDAP or Active Directory inside the enterprise domain usually protected by a firewall. Apps 1 and 2 are deployed inside the domain of the enterprise while App 3 is deployed on Google App Engine (different domain) . The user may access the resource either when he is inside the enterprise, or when outside from a kiosk, etc.

Authentication :
In all cases, the user should be authenticated using credentials of the enterprise. Google App Engine credentials may be used for single sign on but it is not mandatory.

Authorization :
The system administrator should be able to define access management rules for the user based on the user's identity inside the enterprise.

Here is how RSA Access Manager can be configured to access the authorization-rules server to determine access to users. Firstly, we would require an Access Manager agent at the Google App Engine server. App Engine Java version provides Server filters that intercept requests before they access the actual resource. Here is how the work flow proceeds.

1. User accesses a resource on App engine. He is not logged into Google or on the enterprise.
2. The filter intercepts the request and does a URLFetch to the Access Manager Authorization-rules engine, deployed inside the firewall.
   
3. This communication is secured by using Google Secure Data Connector. This could also have been secured using mutual SSL if URL Fetch would allow it.
4. The server sees that the there is no cookie set in the request and replies to the agent that authentication needs to be performed.
   
5. The agent sends back a redirect response that throws the user to the authentication page hosted inside the enterprise domain.
6. User authenticated at this page. If the user is inside the enterprise, he could be authenticated using NTML, etc.
7. If credentials are correct, a cookie for the enterprise domain is set.
   
8. The user is then redirected to the resource page, carrying a message from the server to set a cookie for the Google domain.
   
9. The agent sets the cookie and again redirects to the resource page.
10. Since the resource is still protected by the filter, the filter kicks in again and does a URL Fetch to the server to see if the user is allowed.
    
11. The server sees the cookie that is sent in this request and decides on if this user is allowed access or not.
12. The agent sees the reply from the server and redirects or blocks the user, depending on the response.
    

This case become a little complicated if resources are protected using Google credentials, as specified in the app config file. This is the case where single sign on and federation is required; details about this in a later post.

Hence, using this simple filter, you can protect your applications that have moved to the external cloud just like resources are managed inside the enterprise. Adequate measures to secure the communication between the agent in App engine and the Authorization server ensure that this deployment is secure like it was when inside the firewall.

Flash Resizer : Toggle it on and off

This is a continuation in the Flash Resizer Bookmarklet series that I had written about some time ago. This post details the capability to toggle the bookmarklet on and off. A couple of people had written to me complaining that the resize capability prevented drag and drop functionality inside the flash. All drag and drop events seem to be picked up by the event handlers assigned by the bookmarklet. Hence, the toggle functionality could be used to remove the event handlers.
The trickiest part in the implementation is maintaining the state between two invocations of the bookmarklet. Since every invocation of the bookmarklet restores the object, all state information should be saved in the Global Window object.
When the resize handlers are assigned, they are also pushed to a global array. On subsequent invocations, the presence (undefined or not) of this object can be used to toggle active or suspended state. If the resizer is to be disabled, the destroy method ofYUI resize is called and elements are popped out of the array. Reactivating would require adding handlers to "move-handler" class elements.
You can drag and drop "Flash Resizer" to your bookmarks toolbar to check out the latest version. Click it once on any page that has flash on it to be able to resize the flash. Thereafter, you can click it to toggle activation and deactivation.

Launchy plugin for WCD

I have found the "Whereever Change Directory"(WCD) tool very useful on the command line. Its a directory changing tool that changes to the directory without requiring to type the whole path. Porting it to Launchy as a plugin would be a great utility.
The windows version of the WCD tool uses a batch file to perform the directory change operations. A batch file by the name wcdgo.bat it created at a location indicated by the wcd.bat file. To use it with Launchy, we would need to append a "start ." statement to the file. Here is the modified version called wcdLaunchy.bat, forked from wcd.bat. This is the file that has to be fed into the Runner plugin with an appropriate keyword in Launchy.

Here is how the batch file looks like.

Flash Resizer : Technical Details

I had written about a bookmarklet that allowed Flash Content on a web page to be resized. This post details the technical details of the code.



To start with, we iterate through all the flash elements - Object tag for IE and Embed to everything else. For flash elements that are opened with wmode="window", we redraw the element with a wmode="opaque". This is done to allow other HTML elements to be drawn on top the element.
Transparent Divs are drawn over flash elements. Click handlers are added to the divs that recreate the flash elements on an "position=absolute" div. This div can be resized and moved (with the YUI resize component). The flash elements with a 100% width and height resize with the div.
There are only a few caveats.

• Shockwave Flash still appears on top of all HTML elements
• Certain flash files do not scale and are fixed. Hence, resizeing the flash does not scale the contents, it just expands the element. Now working on ways to fix this.
  

At Devcamp 2

Flash Resizer

I have often noticed that Flash content on many sites can be better if they could be resized to larger dimensions. Sites like youtube and vimeo do allow full screen videos but it does not really work on multiple monitors where you would want to work on another application. Games also would look at lot better on sites like onemorelevel and miniclip if I could simply maximize the flash and hide other annoying advertisements.
I wrote a simple bookmarklet in the past couple of days that does just that. You can select any flash content, move it and re-size it by dragging the corners. The code is available is here. All you would have to do is add this FLASH RESIZER link to your bookmarks or drag and drop it to the bookmarks toolbar.
Here is how it works. A post about how the code works would follow.

Reddit Bar - Greasemonkey Script

Before Digg released the Diggbar a few days ago, many users may never have bothered to visit the comments page or upmod a story. It was just too much work to upmod a story, specially when the Digg Redirect script took us directly from Google Reader to the story. With the digg bar, it becomes a lot easier for users participate.
I think that the Digg Bar is a great idea and wantedto replicate it for reddit too. Here is a greasemonkey script that you can install to see a similar bar for reddit. Users can toggle between the page and comments by clicking the comments. I find this particularily useful when hitting the comments page from reddit RSS feeds.
The code is simple, it just removes the header, the footer and the right div that displays statistics. It then picks up the details of the story from a div called "sitetable" and places it in the header. The last step is to allow a toggle between the iFrames that displays the target page content and comments.

Tracking those stalkers on Orkut

A few days ago, I had written about a service that would help tracking URLs posted on twitter. I had barely started working on it when a friend told me about tr.im. It is a URL tracking service with statistics.
Apparently, this can also be used for the other use cases - tracking on Orkut and forums. The redirect can be a simple transparent image placed in the forums or Orkut scraps. So, the next time you get a scrap from an annoying stalker, just add a transparent png using tr.im to the scrap that you send. You can also drop the image into all emails and forum posts that you make. This would give you an idea on how far your mail travels or how many people view your posts.
Though the service was written for twitter, you can use it for a variety of services.