-
assigned issue to
John Bradley
- changed status to open
Basic 1.2, Messages 8.14, Discovery 3.1, 3.2 - Issuer Identifier can not contain a path component
Issue #513
resolved
For cloud services, it is important to be able to host different identity providers for different tenants within the same domain, with the IdPs differentiated by the path component of the Issuer Identifier.
This isn't a problem for the SWD phase of discovery, as the "principal" portion of the SWD query already contains information differentiating the different IdPs.
The part of the spec that we'll have to enhance, however, is the GET to the /.well-known/openid-configuration resource in Discovery 3.1. A corresponding "principal" query parameter needs to be added to this request so that the information needed to differentiate between IdPs on the same host can also be passed to this query.
Comments (12)
-
reporter
-
I sent a proposal to the list:
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.
-
Account Deleted
This change also helps address
#479. -
Yes it would allow someone to have there discovery document someplace other than .well-known in the root. However you still need to have SWD in the root .well-known so I don't know that it helps with
#479that much. -
Comparing issuers with path components is a problem.
The closest example we have is SAML where a entityID is restricted to a type of anyURI with a max length of 1024.
Many SAML federations restrict that to https scheme URI in practice.
In XML there is no attempt to compare it other than as a byte string. (there are some parsers that add escaping before comparison, but they generally break things, bad W3C)
So we should say that it is a https scheme URI with only host, port and path components. If the port is 443 it MUST NOT be included. The characters SHOULD be lower case ascii (IDN names are OK with lowercase only).
The comparison MUST be an exact match with no normalization.
Remember the issuer name is coming from SWD so users would never be entering it.
John
-
reporter
Do we want to require that the scheme and host components be lowercase? I would think that we do. As to the path component, I would change it to being RECOMMENDED that all the characters be lowercase. (In many systems, in practice, paths actually are case sensitive. Whether it's a good idea to use this "feature" or not is a different question.)
-
The alternate to appending .well-known is using RFC5988 Web Linking to point at the discovery document when the iss contains a path.
-
reporter
Accepted, but will review after implementations
-
Re
#513remove the no path component restriction from issuer -
Re
#513make changes to allow path in the issuer_identifier -
Re
#513make changes to allow path in the issuer_identifier -
- changed status to resolved
I think I found all of the references to Issuer that needed to be changed.
- Log in to comment
The fix to this this needs to maintain the chain of custody to the issuer that can't be spoofed. Currently we were just depending upon the SSL certificate. This may require the equivalent of federation metadata.
There was a sense of the working group that we need to try to solve this.
John will take a stab at a proposal that works.