[Openid-specs-ab] Multi tenant domain proposal

John Bradley ve7jtb at ve7jtb.com
Mon Jan 23 01:37:37 UTC 2012


The reason not to mess with the port number is that it is a name not a location for comparison purposes.

The Client gets the issuer Name from SWD if they are putting in a port number for some reason, taking it out may not match the iss in the id_token.

https://issuer.example.com/ and https://issuer.example.com:443/  are different URI names and from a security point of view it is better to err on the side of caution.
It also deters people from making generalizations by treating all the port numbers as the same issuer.

If the Name is different it is a different issuer.   

As a practical issue the id_tokens are all going to have ether :443 in them or not.  If the URI SWD is giving out doesn't exactly match your issuer all clients will fail, and it will be fixed.

Putting special case code a bunch of places in clients to special case port 443 being present sometimes and not others is more work and will lead to coding error and debug issues if people expect the client to clean up for sloppy configuration.

Simple solution is people don't include a port number if they are using the default.  The id_token is smaller and life is good.  Everything is a string.  

Now one problem with that is that path is in fact case sensitive. (one issue that the current spec avoids by not having a path).

That opens the question of should the whole thing be compared case insensitively rather than just scheme and authority?
If we do that do we need to preclude IRI because case insensitive may not be meaningful.
There are also issues with "/" vs "\" should they be treated as the same character in the path?
What about % encoded characters?

Probably the best thing from a security point of view is case insensitive on scheme and authority with a exact match on the code points of the path.


John
On 2012-01-22, at 9:41 PM, Mike Jones wrote:

> Thanks for doing this, John!  I'll plan on reviewing it more detail tomorrow.
> 
> I do have one question, though:  Why did you write " Port number normalization MUST NOT be performed.  "https://issuer.example.com/" and "https://issuer.example.com:443/ "  are different Issuer Identifiers."?
> 
> Any implementations counting on https://issuer.example.com/ and https://issuer.example.com:443/  being different Issuer Identifiers just seem like they are asking for trouble!
> 
> 				-- Mike
> 
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
> Sent: Sunday, January 22, 2012 12:38 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Multi tenant domain proposal
> 
> Ticket #513
> 
> Currently issuers are limited to one per host name.  This allows the host's .well-known directory to provide the meta-data for the issuer.
> 
> Currently the spec limits:
> SWD								One per host
> Issuer identifier   						One per host
> Meta-data							One per host
> Registration							One per issuer
> Token, Authorization and user-info		Unlimited
> 
> Nothing stops multi tenant hosts from having a single issuer, and encoding the tenant into the user_id.
> "iss": ="https://foo.com/",  "user_id":="tenant1-1234"
> 
> However if you want to have a custom Authorization landing page and separate discovery and registration endpoints per tenant we need to make a change.
> 
> My proposal is to change iss/issuer from:  
> The https: URL with no path component that the OP asserts as its Issuer Identifier
> 
> To:
> The https: scheme URI with a Authority segment containing a fully qualified HOST, and optionally PORT  components. It may also contain a path component terminated with "/".
> 
> Examples of valid issuer URI are:
> https://issuer.example.com/
> https://issuer.example.com:20443/
> https://issuer.example.com:20443/customer1/
> 
> Issuer identifiers  must be converted to there UTF8 code points for comparison as an octet string.  
> Port number normalization MUST NOT be performed.
> "https://issuer.example.com/" and "https://issuer.example.com:443/ "  are different Issuer Identifiers.
> 
> 
> Discovery Sec 3 changes.
> 
> OpenID Providers MUST make a JSON document available at the URI formed by appending <spanx style="verb">.well-known/openid-configuration</spanx> to the Issuer Identifier. 
> The syntax and semantics of <spanx style="verb">.well-known</spanx> are defined in <xref target="RFC5785">RFC 5785</xref>. <spans style="verb">openid-configuration</spanx> 
> MUST point to a JSON document compliant with this specification.
> 
> Example
> Issuer Identifier																	Discovery URI
> https://issuer.example.com/														https://issuer.example.com/.well-known/openid-configuration
> https://issuer.example.com:20443/													https://issuer.example.com:20443/.well-known/openid-configuration
> https://issuer.example.com:20443/customer1/										https://issuer.example.com:20443/customer1/.well-known/openid-configuration
> 
> This change is backwards compatible with existing IdP.   Some minor changes will be required by clients who are doing discovery.
> 
> With this change we get:
> SWD								One per host
> Issuer identifier   					 	Unlimited per host
> Meta-data							Unlimited per host
> Registration							One per issuer
> Token, Authorization and user-info		Unlimited
> 
> Some cautions.
> This is not crating real separate security domains.  If you control the server you control all of the issuers.
> This will not allow a tenant issuer to move.  Their issuer ID is still tied to the domain name in the Issuer Identifier.
> 
> One thing a company who has a domain that they are purchasing IDM services for could do is use their own domain name to host SWD and discovery and have the endpoints in the discovery document point back to the service provider.  Though you can do that with the existing spec without the change.
> 
> I think the added complexity vs the benefit makes the change worthwhile.  Though I still don't see this being widely used.  
> 
> Let me know and I can start making the changes to the actual specs.
> 
> John B.
> 
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120122/f67eae5b/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list