[Openid-specs-ab] Multi tenant domain proposal

Mike Jones Michael.Jones at microsoft.com
Mon Jan 23 00:41:56 UTC 2012

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

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:

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.

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.

More information about the Openid-specs-ab mailing list