[OpenID] Reuse of expired identities?

Mon Aug 13 02:21:48 UTC 2007

I've been playing, all afternoon, on the very topic of identifier provisioning. 

		As I understand it, OpenID 2.0 has a proposal to solve the accidental
		reuse problem (by allowing for a non-user-visible URL fragment appended
		to the 'real' identifier; said fragment tells an RP which revision of
		http://bob.example.com <http://bob.example.com/>  they're seeing today as opposed to last year).
		This does not address malicious reuse of course but the use case there
		is for large OPs (Yahoo, AOL, etc.) that need to recycle identifiers.

		-John

Now we have a rich set of concepts, a decent object model (from FOAF), OWL -- with which to define the objectClasses, and a rich set of commercial tools, its been fun to play in practice with different identity management models.

What Ive ended up with so far is this (a trivally enhaced version of the JanRain C# implementation of a OP server) 

		"A site has asked for your identity. If you approve, the site represented by the trust root below will be told that you control identity URL listed below. (If you are using a delegated identity, the site will take care of reversing the delegation on its own.) 

		Identity: http://localhost:2997/server2005/user.aspx <http://localhost:2997/server2005/user.aspx>  

		Trust Root: http://localhost:2996/consumer2005 <http://localhost:2996/consumer2005>  

		SAML name: http://localhost:2997/anonpeople/E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2.rdf#E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2 <http://localhost:2997/anonpeople/E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2.rdf#E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2>  

		Allow this authentication to proceed?"

Having performed a local authentication (which happened to be SP-initiated SAML2 SSO), the OP server issues the visual challenge above to the browser user - seeking "informed control".

The SAML protocol operating (entirely hidden) behind the scenes performed a number of  functions:-

1.	
	First, to collect both users HTML and XRDS files, I accessed these resources via an SP-initated WebSSO flow. This incidentially reuqired the user to type a biometrically-recognized key sequence, and then logged the user onto the SAML-IDP, which issued a FormsAuthentication cookie. (As the Janrain initiator is compiled and un changeable  - by me anyways - I had to do some "vendor-specific" http redirecting in order to invoke the SAML SP-Redirect binding. To avoid coding in Boo, I use this feature of the Ping Identity SAML2 server - a feature that may not be available on all SAML2 servers, note.)

2.	
	The JanRain compiled object invoked by the Consumer's HTTPModule then performed an Openid Auth protocol run.

3.	
	The OP server responding to the OpenID Auth protocol run is programmed as a "cardspace-style" gateway, that invites a suitable SAML IDP (selected by means I will relate another day) to make SAML-assertions for the user. The SAML IDP is not informed of the OpenID under test, neither that form typed by the user, nor the person's delegate OpenID form (if any). The gateway obligates the SAML2 IDP to use passiveAuth mode, forcing it to rely on the FormsAuthentication cookie already issued (rather than force the user to go through another biometric proof of presence)

4.	
	SAML2 IDP responds with an Assertion set including attributes. This is unlike Shibboleth, which has the SP come collect the attribute set under "informed control" rules. It is like Shibboleth in that the IDP masks the users local name in the assertion as a persistent pseudonym: E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2 

5.	
	The OpenID/OpenID gateway is configured NOT to use account linking (unlike my experiments of yesterday), but rather maps the inbound name by rewriting, citing the server http(s) endpoint, as http://localhost:2997/anonpeople/E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2.rdf#E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2 <http://localhost:2997/anonpeople/E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2.rdf#E975CDE7725CD9AB825A1C56A0EB38D6BE3883E2>  

6.	
	In the course of the handoff, the gateway writes the inbound SAML attributes as a FOAF file, at the path denoted above.

7.	
	OpenID then continues as normal having relied upon the SAML backroom flow, asking for informed control, as shown above.

Ok. there are number of questions in my mind, having had lots of fun doing this all day - with trivial amounts of coding.

*	
	A. Presumably, the Gateway ought to also write an HTML file, citing that delegate OpenID. The user may reference it subsequently.

*	
	B. A gateway receiving merely an OpenID URI, rather than a user URI, should it present that anonymised OpenID to the user for selection.

*	
	C. Would it be valuable, if we turned account linking back on, that the address/id of the OP server gets hidden from the SAML IDP (by the nature of SP-intiated webSSO with accountlinking, where the SP's SAML server enforces both a naming and gatewaying firewall, through anonymised RelayState)?

*	
	D. Given an valid association now exists between server/gateway and consuemr (given the state machine of OpenID Auth), shoudl the gateway abort the session... and restart it with an OP-initiated authentication, citing the new pseudononymised OpenID?

*	
	E. If D were yes, should the consumer (not the JanRain library) have access to the OP's cert, so it can check its reliability against the FAOF based wot, that it can now so easily de-reference?

Professional disclosure: A-E are a thought experiment, and do not represent an actual practice. Practice stopped at 7. It was fun playing with SAML's encrypted-mode attributes/assertions, and imaging what else one might do with such an advanced id mgt gateway at this (when a non-weekend-warrier programmer gets put in charge!)

________________________________

From: general-bounces at openid.net on behalf of John Panzer
Sent: Sun 8/12/2007 6:42 PM
To: Eric Norman
Cc: OpenID List
Subject: Re: [OpenID] Reuse of expired identities?

Eric Norman wrote:
> On Aug 12, 2007, at 10:07 AM, Peter Williams wrote:
>
>
>>              URLs are DNS-based. When URLs are used as persistent identifiers,
>>the expiration of domain names allows someone who buys a domain name
>>to assume any identities that are tied to that domain name.
>
>
> I don't think this is quite accurate.  It allows someone else to
> "own" the identifier, sure.  But that doesn't mean they can assume
> your identities unless (1) the URL still resolves to your OP, and
> (2) the new owner can prove that they now control that linkage.
>
> I think what it really boils down to is whether or not the new
> URL owner can obtain control of the old OP or obtain a copy of
> its contents.

As I understand it, OpenID 2.0 has a proposal to solve the accidental
reuse problem (by allowing for a non-user-visible URL fragment appended
to the 'real' identifier; said fragment tells an RP which revision of
http://bob.example.com <http://bob.example.com/>  they're seeing today as opposed to last year).
This does not address malicious reuse of course but the use case there
is for large OPs (Yahoo, AOL, etc.) that need to recycle identifiers.

-John

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general