[Openid-specs-ab] Multi tenant domain proposal

John Bradley ve7jtb at ve7jtb.com
Mon Jan 23 20:35:44 UTC 2012


I  agree that having the issuer be a host is the simplest solution and avoids many issues that may cause security problems down the road.

Currently any URI including path or email identifier string can be fed into SWD giving back an issuer.  

In a multi Tenant configuration for discovery you make the issuer names
https://tennent1.host.com/
https://tennent2.host.com/

You use a wildcard cert for *.host.com and serve up different discovery documents for each host.
That then lets you have the actual endpoints on any uri you like.

Encoding the tenant into the path creates lots of issues.

This happens to be a MS ticket.   
I just put forward a straw man proposal on how to do it.

If we don't need to change I am OK with that.

Given that our security is based on TLS certificates (without central meta data), I thought it was logical to map issuers to those identifiable entities.   

John B.


On 2012-01-23, at 5:08 PM, Anthony Nadalin wrote:

> Not sure why we need to concatenate like this since the previous way works w/o screwing with URI in this odd way
> 
> -----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/20120123/b41a7919/attachment.p7s>


More information about the Openid-specs-ab mailing list