[Openid-specs-ab] Multi tenant domain proposal
Anthony Nadalin
tonynad at microsoft.com
Mon Jan 23 20:08:21 UTC 2012
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.
More information about the Openid-specs-ab
mailing list