Thursday, December 18, 2008

PPTP Tunnel and /sbin/route

My SSH tunnel was acting flaky, so I decided to use the PPTP server feature on my DD-WRT router. It was extremely straightforward, though sending all traffic through the tunnel was a non-starter. To fix it, I had to route my "naughty" sites through the VPN and around the corporate network. My router at home is configured to use 192.168.1.0/24

#!/bin/sh
/sbin/route -n add -net login.oscar.aol.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net talk.google.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net imap.gmail.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net smtp.gmail.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net facebook.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net ebay.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net me.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net mail.mac.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net gmail-imap.l.google.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net gmail-smtp.l.google.com $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net 205.188.0.0/16 $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net 64.12.0.0/16 $IPREMOTE >> /tmp/ppp.log 2>&1

This belongs in the /etc/ppp/ip-up config file which should be set as executable. The script is run upon successful connection to the VPN. The last two entries are required to route AIM traffic through the tunnel. The background of this config can be found here: http://www.easyzonecorp.net/network/view.php?ID=572

Monday, October 20, 2008

Apple transcends standards!

Wow. If only it were that easy. "My software is completely standards compliant. No- not with accepted standards, but standards that don't even exist yet!" Marketing just killed interoperability.

Friday, June 13, 2008

iPhone Sprinkler Control?


Why?! The pandemonium!

Yeah, it needs to be polished a bit, but it works!

Tuesday, June 10, 2008

Solving WAYF via Bookmarklets

The power of bookmarklets is still to be seen in many situations. Consider the "Where Are You From?" (WAYF) problem, a common issue with federation technologies. The simple question of where to send the user to complete a federated authentication is one of the more complicated and error prone issues in identity federation. The key metrics for any WAYF solution are that the user should have the opportunity to choose any relevant identity context and the process should be hard for a RP to subvert.

-SAML 1 tokens can be retrieved from an IDP with a specially formed HTTP GET request and a TARGET parameter pointing back to the RP site, though a pre-existing relationship must exist in order to allow this to work since most of the request (attributes, authN) is implicit and expressed in the SAML metadata.

-SAML2 tokens can be retrieved from an IDP with a HTTP POST request which articulates the request parameters (attributes, authN), but still requires the RP to be explicitly aware of supported IDP(s). While there are some tricks in the specification regarding the use of domain cookies, the approach is not very dynamic and is still prone to spoofing and other problems.

-InfoCard solves the problem through the user's selection of a card. The card is indicative of the location of the target identity provider. This is the best approach thus far, though it lacks ubiquity at the moment.

-OpenID addresses the problem by the user being prompted to input their OpenID url. This is the most straightforward approach, as the user is compelled to identify the IDP explicitly (or at least a pointer). Aside from a steeper learning curve, this approach suffers from spoofability assuming a malicious RP (as does SAML).

While all address the problem with varying levels of success, I believe that the bookmarklet approach maintains the benefits of wide interoperability while reducing spoofability of the IDP's interface. The provisioning process would work like so:
  1. The user logs into the IDP for the first time.
  2. The IDP validates user's credentials, offers bookmarklet which can be stored in the user's browser. The bookmarklet has sufficient logic to parse the protocol specific parameters from the RP site required to issue a token.
  3. The user accesses an RP site and navigates to the login page.
  4. The user clicks the IDP's bookmarklet. The bookmarklet's Javascript parses the RP's information and redirects the browser to the IDP's site with the RP's parameters encoded into the URL.
This approach works with all modern browsers. (except IE7, though IE8 works!) It preserves the user centricity of the interaction because the user has to choose an identity bookmarklet to log in, and it reduces spoofability since we are not depending on the RP to preform the redirection. This profile is sufficiently abstract enough that it could be used to improve existing SAML enterprises and could easily be integrated to OpenID.

The bookmarklet code itself is extremely simple. If we use Infocard as our example, we can easily search for the embedded object type of "applicationx/infocard," gather the required/optional claims, and redirect the user's browser to the IDP's site. Assuming the browser supports the "infocard://" protocol:

var idp="infocard://";

var objects = document.getElementsByTagName("object");

var infocardObject;

for(var i = 0; i < objects.length && infocardObject == null; i++){

if(objects[i].type == "application/x-informationCard")

infocardObject = objects[i];

}

if(infocardObject == null){

alert("It appears there is no InfoCard login on this page.");

}else{

var parentElement = infocardObject;

while(parentElement != null && !parentElement.action)

parentElement = parentElement.parentNode;

var target = parentElement == null ? window.location.pathname: parentElement.action;

var requiredClaims=(document.getElementsByName("requiredClaims")[0].value).replace(/\s+/g,'%20');

document.location.href=idp+"requiredClaims="+requiredClaims+"&paramName="+infocardObject.name+"&respondToUrl="+target;

}


If the browser isn't cooperative, then we can replace the idp variable with the hard-coded URL for the IDP, though the user is then forced to have multiple bookmarklets.

Wednesday, June 4, 2008

Apple Java Bug Report

Problem ID: 5903500

* SUMMARY

Java Web Start applications are not receiving file arguments for their associated file types. When an JWS application is installed to the desktop with mime-type and extension associations, the JWS Client correctly invokes the application when attempting to open a related file; it fails, however, to include the file path as a parameter to the JWS application.
* STEPS TO REPRODUCE
1. Install a JWS application to the desktop with a file association in the JNLP file (ex. .xyz).
2. Double-click a .xyz file in Finder. 

* RESULTS
Application launches without any command-line parameters. Expect the subject file to be included as application main() arguments "-open /path/to/file".

Saturday, May 31, 2008

Web-Based Lightweight Card Selector [note]

I should note that the web-based card selector can work with existing IDP's (since we're doing WS-Trust, after all) and with current RP's with Infocard web form/object login with a specially created bookmarklet. This approach opens the door to even current browsers which do not support HTML5. But more on this later.

Web-Based Lightweight Card Selector

Something we've been working on is the ability to create a web-based card selector which will work in situations where a full card selector is not available or appropriate. Since selectors are not yet ubiquitous and inappropriate in many tactical situations, we are working on using a HTML5 based approach to enable an Infocard/CardSpace-based enterprise to work with standard web browsers.
The major changes in HTML5 which allow for this to occur are offline caching (HTML Manifest), the navigator.registerProtocolHandler action, and the DOM/Session storage capabilities. For more information, see Mark Finkle's excellent blog on Firefox 3's offline features and the WHATWG HTML5 Draft Specification for the rest. With these capabilities to be included in future web browsers, we can now assume that the client browser:
  • Can cache URL resources and seamlessly serve them when connectivity to the IDP cannot be established
  • Can route particular protocol requests from arbitrary RP's to a registered IDP web app
  • Can (persistently) store a user's preferences and settings locally, where information regarding trust and disclosures can be held.
With these capabilities, one can begin to see how a web app could operate as a client card selector:
  1. The user accesses an IDP provisioning site, where the card selector resources (HTML, Javascripts, etc) can be retrieved for later use and registered to handle a target protocol such as "infocard://" (perhaps even "openid://"?). At this point, all required Card metadata would be retrieved and stored.
  2. After provisioning occurs, the user access an RP with a login link which specifies the target protocol and any parameters needed for login, e.g. infocard://respondToUrl=[rpurl]&requiredClaims=[claims]&optionalClaims=[claims]
  3. The browser prompts the user to select a registered webapp to handle the invocation, which roughly parallels card selection. Upon selection of the IDP offline app registered in step 1, the browser redirects the user to the cached application. (Note that per the WHATWG draft specification, no information necessarily goes back to the IDP at this point)
  4. The cached web app parses the URL encoded information provided in step two and previews the requested claims to the user. This is analogous to the pre-retrieval step of the Infocard ceremony. The user may select/deselect optional attributes or cancel the transaction at this point.
  5. If the user chooses to continue, the cached Javascript preforms a AJAX WS-Trust RST to the IDP's endpoint specified during provisioning.
  6. The IDP responds with an RSTR which the cached Javascript parses, displaying the display token to the user (for verification) and the security token into an embedded form with the RP's respondToUrl as the action.
  7. After review, the user chooses to submit the token, which is posted to the RP site in the same fashion as current card selectors (HTTP POST with a xmlToken value).
This approach seemingly solves the problem of a lack of card selectors and lightweight clients assuming that all major browser implement HTML5 (which appears to be the case). The above approach actually works as demonstrated by our proof of concept which uses only Firefox 3 or any browser with Google Gears. 

The registerProtocolHandler (and possibly even the MIME handler) seem to have a number of possibilities within the federated identity communities. As demonstrated above with the Infocard scenario, this can address the vexing "Where are you from?" problem which plagues web-based federated identity solutions including OpenID. Omitting the RP from the redirection phase via the web app selector and a carefully crafted offline web app should do wonders to reduce spoofability and increase usability.

While this is a big step to lightweight identity selectors, it does lack a number of the nice features available in a full card selector:
  • Cannot provide "clues" regarding the applicability of registered web apps (such as disabling cards/webapps which are inappropriate for the required claims)
  • Cannot easily integrate with the OS for things such as public/private key creation, thus this is clearly aimed toward managed card with browser-friendly authentication.
  • Encryption in Javascript is hard. XMLEnc with the RP's certificate isn't possible with this approach, so we have to depend upon Audit mode or unencrypted tokens over HTTPS.

Below is a simple web-based card selector provisioning data flow, though I forgot to put in the card metadata exchange in step 4. 



The offline cache is much more useful than just for the protection of the user privacy; once offline tokens within Infocard become possible, this approach should still be very viable. I have a screencast of our demo and I'll update this post when I get around to uploading it to YouTube. 

Thursday, May 29, 2008

IPhone Garage Door Opener

In a past life I wrote automation controllers for large facilities. Now, I'm obsessed with needlessly automating my house (since it's my first). Thus, I present to you, my latest in ridiculously over-engineered automations:

The iPhone Garage Door Opener

Why? Cause it's cool to be able to press a button on my phone and have my garage door open. That, and, I have a horrible habit of leaving my garage door open all night for anyone to access, and now I can create a script to remotely close the door at a given time.

The stuff I bought consists of an NPort 16 port serial server (5610, if I remember) and an National Control Devices ProXR 4 Relay, 8 Input serial controller. To sense state, I included a garage door contact sensor with input into the ProXR. 

On my MacPro, I have Tomcat running with a servlet which responds to the AJAX calls from my little iPhone-customized JSP page. The UI updates every 5 seconds, updating the door state and the current temperature in the garage (since a temperature sensor comes on the ProXR). So now I can use my iPhone to control my garage (which is almost useful)!