Implementing CustomStore with unsolicited assertion in OpenIdRelyingPartyWebForms Example?

[Richard Collette]

I've tweaked the OpenIdRelyingPartyWebForms example to work with unsolicited assertions.  I now want to turn on

the use of the CustomStore in the example.  I did this by uncommenting the <store> element in the OP and RP sites.  However, a call is made to CustomStore.GetKey in the RP and I get a

null exception.

The bucket is the same on each call ("http://localhost:4860/Provider.ashx") but the handle is unique each time. 

So my assumption is that there is no way GetKey in the RP can return a value since it did not make the request in

the first place.  Under that assumption, I changed the GetKey implementation in the RP to return null, rather than attempting to create a new CryptoKey, if FindByBucketHandle returned null.

public CryptoKey GetKey(string bucket, string handle) {
  var assocRow = dataSet.CryptoKey.FindByBucketHandle(bucket, handle);
  if (assocRow == null)
  {
     return null;
  }
  return new CryptoKey(assocRow.Secret, assocRow.ExpiresUtc);
}

Making this change, the example runs correctly.  Is this a valid implementation of GetKey?

 

Now that I have enabled the use of the application store through configuration, by what mechanism is is the RP validating the signature of the provider since there are no preconfigured shared secrets in the application store (that I am aware of).   Is this done solely in the callback to the provider?  If so, how does this prevent something like dns spoofing?

 

Am I correct in my assumption that if I use the store element in configuration, I do not have to specify the store implementation in the constructor of the OpenIdRelyingParty class?

 

Thank you,

Rich

 

 

 

  

[Andrew Arnott]

Inline...

On Tue, May 8, 2012 at 9:54 AM, Richard Collette <richard....@gmail.com> wrote:

I've tweaked the OpenIdRelyingPartyWebForms example to work with unsolicited assertions. 

What tweaks did that take?  For me it works out of the box.

 

I now want to turn on

the use of the CustomStore in the example.  I did this by uncommenting the <store> element in the OP and RP sites.  However, a call is made to CustomStore.GetKey in the RP and I get a

null exception.

The bucket is the same on each call ("http://localhost:4860/Provider.ashx") but the handle is unique each time. 

So my assumption is that there is no way GetKey in the RP can return a value since it did not make the request in

the first place. 

Correct.  

 

Under that assumption, I changed the GetKey implementation in the RP to return null, rather than attempting to create a new CryptoKey, if FindByBucketHandle returned null.

public CryptoKey GetKey(string bucket, string handle) {
  var assocRow = dataSet.CryptoKey.FindByBucketHandle(bucket, handle);
  if (assocRow == null)
  {
     return null;
  }
  return new CryptoKey(assocRow.Secret, assocRow.ExpiresUtc);
}

Making this change, the example runs correctly.  Is this a valid implementation of GetKey?

Absolutely.  And thank you for reporting this.  I've checked in a fix for the next release. 

 

Now that I have enabled the use of the application store through configuration, by what mechanism is is the RP validating the signature of the provider since there are no preconfigured shared secrets in the application store (that I am aware of).   Is this done solely in the callback to the provider?  If so, how does this prevent something like dns spoofing?

In this unsolicited assertion flow, you are correct.  DNS poisoning is mitigated by the Provider using HTTPS for its OP Endpoint and the Claimed Identifier itself.

 

 

Am I correct in my assumption that if I use the store element in configuration, I do not have to specify the store implementation in the constructor of the OpenIdRelyingParty class?

That's right.  On the flipside, you can set the store programmatically instead of the config file -- whichever you prefer is fine.

[Richard Collette]

Sorry... just getting back to reading these and wanted to thank you for answering.  Had a bit of a heartache when a partner using python refused to do OpenId despite previously saying "they would do it if we really wanted to."    So now we're looking at X509 certificate based encryption and signing with a random identifier used for replay prevention.  Sound vaguely familiar?   Ugh.  We're pressing ahead with OpenId for other partners though.