Question

I’m building a new project and I’m having some debate over how it needs to be developed. The big picture is to develop a consumable JavaScript widget that other internal developers can embed into their web applications. The trick is that the consumer needs to be able to tell me what AD user is currently logged into their page…and then I need to trust that the passed username is coming from the consumer and hasn’t been tampered with via outside sources.

The overall solution needs to have a VERY simple set-up on the consuming side involving no compiled code changes. Also it needs to be functional across both ASP.net and PHP applications (hence my decision to go with JavaScript).

Overall, it’s kind of like an Oauth solution…except the trust between domains can be intrinsic since I’ll already know every user in the company trusts the host domain.

I started stubbing it out and got kind of stuck. My idea was that I would basically host a JavaScript file that the client host could embed in their page. During their page load cycle, they could init my JavaScript widget and pass it a plain text username (all I really need). Somehow I would establish an secure trust between the client host’s web page, and my widget so that it would be impossible for a third-party to embed my widget into a false web page and send action commands under a user other than their own.

I hope this makes sense to someone.

Answer 1

I haven’t really discovered an answer so to speak, but I’ve decided on a method:

So, I decided on a pattern where I write my JavaScript and HTML widget using the proposed jQuery UI Widget Factory. That allows the my consumer to implement the widget using simple syntax like:

<script src="widget.js"></script>
$('#someElement').myWidget({ encryptionUrl: handlerPath }); 

Now, you’ll noticed that as part of my widget, I ask the consumer to pass a “handlerPath.” The “handler” is simply an Microsoft MVC Controller which is in charge of getting the logged in user, and encrypting the call.

So the handler in my app looks something like this…

[Authorize]
public JsonpResult GetToken(string body, string title, string sender)
{
    Packet token = new Packet();
    try
    {
       // Get the widget host's public cert
       string publicKey = "some.ssl.key.name.here";
       // Get the consumer host's private cert
       string privateKey = "this.consumers.ssl.key.name.here";

       // Build a simple message object containing secure details
       // Specifically, the Body will have action items (in JSON) from my widget
       // The User will be generated from the consumer's backend, thus secure 
       Message message = new Message(){
        Body = body,
        Title = title,
        User = System.Web.HttpContext.Current.User.Identity.Name,
        EncryptionServerIP = Request.UserHostAddress,
        Sender = new Uri(sender),
        EncryptionTime = DateTime.Now
       };

       PacketEncryption encryption = new PacketEncryption();
       // This class just wraps basic encryption and signing methods
       token = encryption.EncryptAndSign(message, publicKey, privateKey);
       token.Trust = "thisConsumerTrustName";
    }
       catch (Exception exception)
    {
       throw;
    }

   return this.Jsonp(token);
}

Now, I have an encrypted “token” which has been encrypted using the widget host’s public key, and signed using the widget consumer’s private key. This “token” is passed back to the widget via JSONP from the consuming server.

My widget then sends this “token” (still as JSONP) to it’s host server. The widget hosting server has decrypting logic which looks something like this.

public Message DecryptAndVerify(Packet packet, string requestIP)
{
    if (packet == null) throw new ArgumentNullException("packet");
    if (requestIP == null) throw new ArgumentNullException("requestIP");

    Message message = new Message();

    try
    {
        // Decrypt using the widget host's private key
        RSAEncryption decrypto = new RSAEncryption("MyPrivateKey");
        // Verify the signature using the "trust's" public key
        // This is important because like you'll notice, I get the trust name
        // from the encrypted packet. I then maintain a "trust store" mapping 
        // in my web.config, or SQL server
        RSAEncryption verifyo = new RSAEncryption(GetPublicKeyFromTrust(packet.Trust));

        string decryptedJson = decrypto.DecryptString(packet.EncryptedData);

        // Verify the signature
        if (!verifyo.Verify(decryptedJson, packet.Signature))
        {
        Exception ex = new Exception("Secure packet was not verified. Tamper evident");
        throw ex;
        }

        // If the message is encrypted correctly, turn it into a message object
        message = decryptedJson.FromJson<Message>();

        // Verify the ip
        if (message.EncryptionServerIP != requestIP)
        {
        Exception ex = new Exception("Request IP does not match encryption IP. Tamper evident");
        throw ex;
        }

        // Verify the time
        if ((DateTime.Now - message.EncryptionTime).Seconds > 30)
        {
        Exception ex = new Exception("Secure packet is too old");
        throw ex;
        }

    }
    catch (Exception ex)
        {
            throw ex;
        }
    return message;
}

The idea is that the JavaScript widget determines the secure actions the end user wants to take. Then it calls back to it’s host (using the handler path provided by the consumer) and requests an encrypted token. That token contains the IP address of the caller, a timestamp, the current AD username, and a bundle of actions to be completed. Once the widget receives the token, it passes it over to it’s own host server at which point the server checks to make sure that it is

• Signed and encrypted properly according to predefined trusts
• Not older than 30 seconds
• From the same IP as the initial request to the consumer’s server

After I determine those checks to be valid I can act on the user’s actions by creating a WindowsPrincipal identity from the string username like this:

WindowsPrincipal pFoo = new WindowsPrincipal(new WindowsIdentity("username"));
bool test = pFoo.IsInRole("some role");

All said and done, I have established a trusted request from the widget consumer, and I no longer have to prompt for authentication.

Hopefully this helps you out. It’s been running in my internal environment for about a month of QA and it’s it’s working great so far.