12 Nov 2009 @ 9:36 PM 

Ran into an interesting problem yesterday where a few months ago we helped a client redesign an ASP.NET web application to fit it into an iframe within their CMS rather than being a standalone site.  Easy enough task.  Testing is completed and site is rolled out.

Now, several months down the road after the application has been iframe’d and in production – one random feature of the application is unexpectedly breaking, but it doesn’t make any sense – the only way the behavior could possibly occur would be that an object retrieved from Session is coming back as null, which turned out to be the case.  The browser was somehow losing the ASP.NET Session cookie.  Furthermore, the feature was working fine in Firefox but not in Internet Explorer, very strange.

The problem was that Internet Explorer will not accept cookies from a page within an iframe where the domain name is different from the top level page.  So, the url of the iframe’d page was www.clientsite1.com and the url of the page hosting the iframe was www.clientsite2.com.

To get around this, you need to add a P3P Compact Policy to your HTTP responses.  P3P is a protocol that allows websites to pass information to the browser regarding their intent to use information collected from the user.  Internet Explorer is the only browser that implements the protocol, and only using it for cookie blocking at that.

To add a P3P in ASP.NET that will allow your cookies to be accepted by the browser from a different domain from within an iframe, add this block of code to your Global.asax.

protected void Application_BeginRequest(object sender, EventArgs e)
{
     HttpContext.Current.Response.AddHeader("p3p","CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\"");
}
Posted By: admin
Last Edit: 12 Nov 2009 @ 10:25 PM

EmailPermalinkComments (0)
Tags
Tags:
Categories: Uncategorized
 08 Nov 2009 @ 10:27 PM 

Microsoft showed us Photosynth while we were touring the MTC in downtown Chicago a few months ago.  Photosynth is an impressive new Silverlight-based technology they’ve been working on that can be used to stitch hundreds of images together into a single explorable, zoomable, pannable, and web-viewable panoramic image.   I was looking for a situation where I could possibly make use of Photosynth since I first saw it.   The amazing panaromic views of Isle Royale National Park in Michigan proved to be the perfect opportunity.

The photosynths are easy to make – just stand in one place, turn in a circle and take about 50-100 overlapping pictures.  Be sure to zoom in a few times and take some detail shots.  After downloading the Photosynth client and selecting photos to stitch, some pre-processing takes place on your computer and the images are uploaded to the Photosynth website where the final combined result can be viewed.  The resulting photosynth can be embedded in a web page.

You can see an example from Isle Royale below.  Give it a few seconds to load for a better experience while zooming around.  Use the mouse wheel to zoom in and out, and drag the picture around to pan.

Posted By: admin
Last Edit: 08 Nov 2009 @ 11:58 PM

EmailPermalinkComments (0)
Tags
Tags: ,
Categories: Uncategorized
 04 Nov 2009 @ 10:37 AM 

In reading various blog posts, forums, and Stack Overflow questions there is still quite a bit of confusion around the different data storage options available in Windows Azure.  This is probably mostly due to Microsoft changing their strategy, architecture, and naming conventions a few times.

For example, SQL Azure used to be called SQL Server Data Services (SSDS), was non-relational, and used an Entity Attribute Value (EAV) schema – giving it a major overlap in the functionality of Azure Table Storage.  This obviously provided a pretty poor migration path to the cloud for existing applications using relational SQL Server storage.  It was also confusing for developers, seeing that there were two non-relational storage options.  So, Microsoft dumped/revamped SSDS and turned it instead into the now fully-relational hosted SQL Server offering, SQL Azure.

Below I’ve outlined some key bullet points around the various Azure storage options, as well as when each option should be used.

Azure Blob Storage

  • You can think of blob storage as the file system of Windows Azure.
  • Blobs are stored in blob containers.  You can think of a blob container as a folder.
  • You can give a blob a primary key and some key/value metadata when you upload the blob to storage.
  • Use the StorageClient class included with the Windows Azure SDK Samples to interact with blob storage from .NET (rather than using the REST API directly).  This greatly simplifies things and adds some additional functionality like retries on failed calls.
  • Use blob storage to store anything that you would normally store as a file or database blob.
  • Querying is very limited – you can only pull a list of blobs by their container or by their primary key.
    • There are two steps to retrieving a blob – first you pull the metadata, and then you make a separate call to pull down the actual byte content.  For example, retrieving a list of blobs by their container retrieves a list of blob metadata.  This prevents you from pulling unnecessarily pulling down a ton of data.
  • Azure Blob Storage can be accessed from within the cloud or from outside of the cloud (i.e. a desktop or intranet application).  Your blob storage API URL is publicly accessible, however it requires the use of a secret key to access unless you’re retrieving public blobs.

Azure Table Storage

  • Use Azure Table storage to store simple structured data and objects.
  • You can think of Azure Table Storage as a bunch of stand alone object tables with no relation to each other.  There are no real foreign keys except what you implement on your own.
  • Azure table storage is implemented as an Entity-Attribute-Value (EAV) database in the backend, but this is mostly abstracted via the StorageClient class included with the Windows Azure SDK samples.
  • You can store more than one type of object with varying properties in a table, but this is not recommended for the sake of keeping things simple.  This at least allows your objects to evolve over time as you add/remove fields.
  • Every object that you store in Azure Table Storage must have a PartitionKey and a RowKey.
    • The combination of the Partition Key and Row Key is the Primary Key.
    • The Partition Key and Row Key are the only indexed values on the objects.
    • The Partition Key can be used to logically partition data within your tables if required – though you can hard code the Partition Key if you don’t need it.
    • The Row Key should be a unique key within the partition.  You could use a Guid, for example.
  • You can query Azure Table Storage via LINQ, though not all operations (i.e. scalars) are supported.  Performance would definitely be a factor on queries from an EAV database.  Make use of the indexed partition and row keys if possible for faster querying.
  • Azure Table Storage can also be accessed from within the cloud or from outside the cloud (i.e. a desktop or intranet application).  Your table storage API URL is publicly accessible, however it requires the use of a secret key to access.

Azure Queue Storage

  • The main use of Azure Queue Storage is for communication between your Azure web and worker roles or between worker roles, i.e. for picking up and dropping off data to be processed.
  • Can pass simple string messages in a queue.
  • Similar to other message queueing frameworks.
  • Also can use the StorageClient class in the Windows Azure SDK samples to abstract the HTTP REST API.

SQL Azure

  • SQL Azure is very similar to an on-premise SQL Server databases.
  • You can currently create a 1 GB database (currently $9.99/mo) or 10 GB database (currently $99/mo).  Much more expensive than Windows Azure Storage options (blob/table/queue).
  • Use SQL Azure for storing complex relational data – i.e. any time you would normally store data in a database.
  • For the most part, you can simply change your SQL Server connection string to point to your SQL Azure connection and your application will work fine in most cases.
  • Your SQL Azure instance is publically accessible via a SQL TCP connection over the internet.  You can retrieve the connection string for your database from the SQL Azure dashboard.
    • Though the database is publicly acessible, you are given access to create basic inbound firewall rules for which hosts are allowed to access your SQL Azure database.  For example, you can set it up such that your database is only accessible from within your Windows Azure roles or you could set it up such that it would only be accessible from IPs originating from your organization.
  • SQL Azure has much of the same capabilities as on premise SQL Server, i.e. full T-SQL querying capabilities, indexing, stored procedures, triggers, views, etc.
  • You can connect to SQL Azure via all the standard methods, i.e. ODBC, ADO.NET, PHP Drivers, LLBL, NHibernate, Entity Framework, etc.
  • Some features are not supported including SQL Profiler, backup, replication, filegroups, manipulation of physical file resources, etc.
  • Many of the unsupported features are taken care of for you by Azure, i.e. backup, replication, high availability, resource governance, etc.
Posted By: admin
Last Edit: 08 Nov 2009 @ 11:59 PM

EmailPermalinkComments (1)
Tags
 02 Nov 2009 @ 2:35 PM 

I recently ran into a situation where a client wanted to place their public facing ASP.NET website behind Oracle SSO to allow their customers to log in via their existing Oracle SSO accounts, yet also allow anonymous users to use the application without logging in.  We could have done a simple LDAP integration, but the client also wanted users to not have to log into the application if they’re already logged into their Oracle Portal account.

First step, we had to determine how to get Oracle SSO running on Oracle Application Server (OAS) to protect an application running on a separate IIS web server. In order for an ASP.NET application to be able to get user credentials from Oracle SSO, Oracle SSO has to run “in front of” your application – i.e. something has to intercept the browser request on the way to your web app, decrypt their SSO session cookie, and inject an HTTP header containing the the user’s username that your ASP.NET application can read. There are two ways to accomplish this – Apache Reverse Proxying and the Oracle SSO IIS Plug-in.

To preface, Apache Reverse Proxying will route all the calls to your application through Apache first. The other option, the Oracle SSO IIS plug-in is installed on your IIS server, requests are sent directly to the IIS web server, and the requests are intercepted and security is handled by the Oracle plugin.

The Apache reverse proxy will pass all calls sent to a URL in OAS to a site running on another web server.  For example, OAS will take all browser requests to http://oas.client.com/iissite/ and proxy them to http://iis.client.com/.  Responses from IIS will be sent back to OAS and OAS will send the response back to the originating web browser.  In testing this proved to be a little slow, as every single request to the application – images, javascript, css, ajax, postbacks, etc. would all  be sent through the reverse proxy server and require an additional hop for every time.

On top of the performance issues, the ASP.NET application had to run in the root of the IIS web server and use a host header to route requests to the proper site.  ASP.NET uses relative paths (i.e. <script src = ‘/ScriptResource.axd?etc…’/>) for included javascript used in ASP.NET AJAX and ASP.NET validation controls (ScriptResource.axd and WebResource.axd).  Normally this would work fine if the web requests were being sent directly to the IIS server.  However, when behind the reverse proxy server (remember, IIS has no idea it is serving pages behind a reverse proxy) – this causes the web browser to try to retrieve the javascript files from http://oas.client.com/ScriptResource.axd (directly from the OAS web server – where ScriptResource.axd obviously doesn’t exist and will send back a 404 error) instead of properly retrieving the files from http://oas.client.com/iissite/ScriptResource.axd.  This causes all of the ASP.NET AJAX and ASP.NET validation controls to break.

There isn’t any way to get ASP.NET to retrieve those resources from a different path or to somehow prepend a path to the ScriptResource.axd and WebResource.axd URLs.  The ScriptResource.axd issue can be fixed by manually including the individual ASP.NET AJAX javascript files by setting the ScriptPath on your ScriptManager.  This is a pain, but works fine with the Reverse Proxy and the browser will be able to properly retrieve the ASP.NET AJAX files.  Unfortunately, this still leaves the WebResource.axd pointing to the wrong path. WebResource.axd is used to retrieve the javascript used in the client-side validation for ASP.NET Validator controls and without it all client-side validation will be broken.  There isn’t any way that I could find to modify where ASP.NET will retrieve those files.  To get around the .axd issue, we had to get creative and create an IHttpModule that would rewrite the HTML responses and fix the paths on the fly.

Doing a simple find and replace on the .axd paths works fine for regular postback responses to fix the bad paths, but fails with ASP.NET AJAX partial-page updates.   You can find and replace in the partial-page updates, but then it will throw off the field lengths in the pipe-separated data that is sent back to the browser.  Thus, you need to actually find and rewrite the field lengths on the fly as well whenever you do a replace on the .axd paths.  You can see the implementation of this in the ReverseProxyPathFixModule.cs below – it is a little scary, and I’m sure it isn’t full proof because the partial page responses are chunked upon being sent back to the browser.  If there was an .axd path in between chunks, it wouldn’t be replaced – but I never saw this happen.

The most relevant portions of the code below are the Write() methods of PageFilter and PartialPageFilter – they do all the work. The rest of the code is just overridden Stream methods.

View ReverseProxyPathFixModule.cs

After implementing the custom HttpModule, the application was working almost perfectly behind the Reverse Proxy.

For the next hurdle, we couldn’t find any way to have Oracle SSO protect a resource in IIS (or even running in OAS for that matter) while allowing both anonymous and authenticated access.  There isn’t any built-in way to allow anonymous access to an application while it is protected by Oracle SSO.  After much research and reading this Extending Oracle SSO presentation and this Integration with Third-Party Access Management Systems help documentation from Oracle, we decided to create a custom Oracle SSO module that would “authenticate” a user and pass them to the application as the Oracle Portal “PUBLIC” account if they weren’t already logged in to SSO.  The implementation of this plugin is fairly simple – it’s a Java class that inherits from the default Oracle SSO module (SSOServerAuth) and implements the IPASAuthInterface interface.  The code simply checks the user’s cookies on the request – if the user has an Oracle Portal cookie, perform the authentication from the base class  by calling super.authenticate.  If the user doesn’t have a portal cookie, pass them on to the application and “authenticate” them as the PUBLIC user account.  This is definitely a hack, but it works pretty well.  See the implementation of the MixedAuthentication below.

View MixedAuthentication.java

Compilation of the code is a little tricky, you need to include ipastoolkit.jar, ossocls.jar, and servlet.jar in your classpath.  The ossocls.jar isn’t usually included or detailed in the documentation because most Oracle SSO plugins don’t inherit from SSOServerAuth (it isn’t required), but rather just implement IPASAuthInterface.  Deployment is also tricky, fortunately I found this blog post ‘Adding reCAPTCHA to Oracle SSO‘ that detailed how the plugin should be deployed to OC4J_SECURITY container, rather than the standard $ORACLE_HOME/sso/plugins location.

More hurdles! After successfully setting up our custom authentication plugin, we couldn’t figure out how to have our reverse proxy’d application use the custom plugin without it also affecting the client’s Oracle Portal installation.  After we would set the reverse proxy path to use the custom plugin, we would see strange behavior in the Oracle Portal even though portal would be set to use the standard MediumSecurity and our reverse proxy path would be set to use our custom ‘MixedSecurity’ setting.

This is how we tried to set up our Oracle SSO policy.properties file:

#add our custom security level.
MixedSecurity = 70 

#keep the default authentication level so as to not affect oracle portal security.
DefaultAuthLevel = MediumSecurity

#set our custom app behind reverse proxy to use our new custom security level.
oas.client.com/iissite\:80 = MixedSecurity
#not sure if you need the path on OAS or the reverse proxy site. also tried it this way.. didn't work.
iis.client.com\:80 = Mixed Security

#set the plugin class for our custom security level
MixedSecurity = com.client.authentication.MixedAuthentication

No matter what we tried with the SSO configuration we couldn’t get our application behind the reverse proxy to be protected by our custom plugin without also affecting the security of Oracle Portal.  If anyone knows how to actually do that, I’d be interested to hear where we went wrong in the comments.  Unfortunately, this meant that the work with the custom HttpModule, setting up the reverse proxy, etc. was all for naught.  We had to install the Oracle SSO IIS plugin.  This plugin is somewhat of a beast – the installation and configuration is one of the most complicated and least user-friendly  I’ve ever encountered and involves creating registry entries manually, providing many opportunities to make mistakes along the way.

Either way, after installing the IIS plugin everything worked fairly smoothly.  One thing to note – if you want to redirect the user from your ASP.NET application to log in to their actual Oracle SSO account rather than the PUBLIC account, you need to delete the user’s cookie that will look something like IAS_IDXXXXXX – this will “log out” the user from the PUBLIC account.  If the user isn’t logged out of the PUBLIC account before hitting the SSO logon page, they’ll be automatically redirected (to the url provided in the p_requested_url parameter when sending the user to the SSO logon page) when they hit the page because they’re actually already logged in to the PUBLIC account.

One remaining problem, the Oracle SSO IIS plug-in manages to randomly crash the worker process with an error like:

Faulting application w3wp.exe, version 6.0.3790.3959, stamp 45d6968e, faulting module oracle_osso.dll, version 0.0.0.0, stamp 41775fa1, debug? 0, fault address 0×00002454.

Checking the SSO plug-in log files yields nothing out of the ordinary either so this has been pretty difficult to track down, we still haven’t found any solution for this problem.   If anyone knowledgeable on the IIS or Oracle SSO side of things has some ideas or has seen this before, feel free to let me know in the comments.

Finally, after your ASP.NET application is safely behind Oracle SSO you can determine the logged in user’s username by checking the OSSO-USERNAME header like so:

protected override void OnInit(EventArgs e)
{
string username = request.Headers["OSSO-USERNAME"]
//do whatever you like with the username
}

After that, the user’s username from Oracle SSO will come over on the HTTP headers on every request to your application.

Posted By: admin
Last Edit: 04 Nov 2009 @ 09:52 AM

EmailPermalinkComments (3)
Tags
Change Theme...
  • Users » 1
  • Posts/Pages » 10
  • Comments » 13
Change Theme...
  • VoidVoid « Default
  • LifeLife
  • EarthEarth
  • WindWind
  • WaterWater
  • FireFire
  • LightLight

About



    No Child Pages.