OpenID Unsolicited Positive Assertion Verification?

[Richard Collette]

I've finally read the full OpenId spec and now have some questions related to unsolicited positive assertions.

When the OP creates an unsolicited positive assertion, is a private association created?  If so where does this get stored or come from?   If stored is there a data store extension point (override)?

I modified the OpenId OP and RP example sites to perform an unsolicited assertion.  It does not appear to me, at least looking at the logs, that the RP performs direct verification of the unsolicited positive assertion.  Is this correct?  If no direct verification is performed, it seems to me that there must be a "stored" mutual shared key (MAC) being used and if so, is there an extension point (override) for storage and retrieval of the shared key associated with each OP/RP endpoint?

Thanks again for your direction.
Rich

[Richard Collette]

DOH!.    I just found the direct verification:

2012-04-12 15:59:34,517 (GMT-4) [5] DEBUG DotNetOpenAuth.Messaging.Channel - Preparing to send CheckAuthenticationResponseProvider (2.0) message.

But the question on the private association still stands.

Thanks
Rich

[Andrew Arnott]

Unsolicited assertions always use private associations.  And the way the OP stores this is the same way it stores private associations for "dumb mode" RPs that can't store shared associations.  In DNOA v3.x this was via the IAssociationStore if I recall correctly.  In DNOA v4.x this is via the ICryptoKeyStore.  And yes, they both default to in-memory stores that don't work well in web farm or other production environments but are extensibility points that should be implemented with a database backend for reliability and enhanced security.

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/rv7ZfV-rhyQJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Richard Collette]

I just realized that after the assertion is verified, the RP further verifies that the "assertion matches identifier discovery results".  If the entire unsolicited assertion is sent back to the provider and verified, wouldn't that then mean the identity within the assertion has already been verified?   I'm not sure what the identity verification step accomplishes (or what bad thing it prevents from happening.

 

On Thursday, April 19, 2012 10:31:04 PM UTC-4, Andrew Arnott wrote:

Unsolicited assertions always use private associations.  And the way the OP stores this is the same way it stores private associations for "dumb mode" RPs that can't store shared associations.  In DNOA v3.x this was via the IAssociationStore if I recall correctly.  In DNOA v4.x this is via the ICryptoKeyStore.  And yes, they both default to in-memory stores that don't work well in web farm or other production environments but are extensibility points that should be implemented with a database backend for reliability and enhanced security.

On Thursday, April 19, 2012, Richard Collette wrote:

DOH!.    I just found the direct verification:

2012-04-12 15:59:34,517 (GMT-4) [5] DEBUG DotNetOpenAuth.Messaging.Channel - Preparing to send CheckAuthenticationResponseProvider (2.0) message.

But the question on the private association still stands.

Thanks
Rich


On Thursday, April 19, 2012 3:34:39 PM UTC-4, Richard Collette wrote:

I've finally read the full OpenId spec and now have some questions related to unsolicited positive assertions.

When the OP creates an unsolicited positive assertion, is a private association created?  If so where does this get stored or come from?   If stored is there a data store extension point (override)?

I modified the OpenId OP and RP example sites to perform an unsolicited assertion.  It does not appear to me, at least looking at the logs, that the RP performs direct verification of the unsolicited positive assertion.  Is this correct?  If no direct verification is performed, it seems to me that there must be a "stored" mutual shared key (MAC) being used and if so, is there an extension point (override) for storage and retrieval of the shared key associated with each OP/RP endpoint?

Thanks again for your direction.
Rich

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/rv7ZfV-rhyQJ.
To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

[John Bradley]

The discovery step is required because openID 2.0 supports delegation.   The claimed_id may not be in the same domain as the OP.   

Without the discovery step to check that the OP is authoritative for that claimed_id you have zero security.  Any OP can send a valid unsolicited assertion for any identifier.

John B.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/mfRM00kbz-8J.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

[Richard Collette]

Thank you for the response.   I'll have to re-read the spec because the portion about delegation must not have stuck with me.

[John Bradley]

From a security point of view, it is discovery that tells you who the OP is for any identifier.

Normally that is done first and if the claimed identifier doesn't change you don't need to redo discovery if the RP is maintaining state.

The OP can change the claimed identifier to anything in the response.  If that happens or if it is a unsolicited assertion then the RP MUST redo discovery.

I hope that helps.

John B.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/kQZevlYTKOoJ.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.